MongoDBのレプリカセット運用中に「not master」というエラーに遭遇し、お困りでしょうか？ ご安心ください。このエラーはMongoDBレプリカセットの基本的な動作を理解すれば、すぐに解決でき、再発防止策も講じることができます。この記事では、Windowsユーザーの皆様が直面している「not master」エラーを迅速に解決し、恒久的な対策を立てるための具体的な手順を、PowerShell/Cmdコマンドを交えてご紹介します。
目次
1. not master とは？（概要と緊急度）
「not master」エラーは、MongoDBレプリカセットにおいて、書き込み操作（データの挿入、更新、削除など）をセカンダリノードに対して実行しようとした際に発生するエラーです。MongoDBのレプリカセットでは、書き込み操作は常にプライマリノードでのみ許可されています。セカンダリノードは、プライマリノードからデータを受け取り、自身のデータを更新する役割（レプリケーション）を担っています。
このエラーは、データの書き込みができない状態を意味するため、アプリケーションが正常に動作しない可能性があり、緊急度は中〜高と言えます。しかし、レプリカセットが正常に機能している証拠でもあり、ノードが壊れているわけではありませんので、ご心配いりません。正しいノードに接続し直すだけで解決することがほとんどです。
2. 【最速】今すぐ試すべき解決策
「not master」エラーの最も一般的な原因は、アプリケーションやMongoDB Shellが、誤ってセカンダリノードに接続していることです。今すぐ以下の手順でプライマリノードを確認し、接続し直してください。
解決策1：プライマリノードに接続し直す
現在のレプリカセットの状況を確認し、プライマリノードがどれであるかを特定後、そのプライマリノードに接続し直します。
手順1: 現在のレプリカセットのステータスを確認する
まずは、PowerShellまたはコマンドプロンプトを開き、MongoDB Shellを使ってレプリカセットのステータスを確認します。
MongoDBのbinディレクトリにパスが通っていない場合は、C:\Program Files\MongoDB\Server\<バージョン>\bin\mongo.exe のようにフルパスで実行してください。
# PowerShellまたはコマンドプロンプトで実行
# 例1: レプリカセット名と複数のホストを指定して接続
# "myReplicaSet"はご自身のレプリカセット名に置き換えてください。
# hostname1:port1 は、レプリカセットのいずれかのノードのアドレスに置き換えてください。
# (例: myReplicaSet/mongodb0.example.com:27017,mongodb1.example.com:27017,mongodb2.example.com:27017)
mongo --host "your_replica_set_name/hostname1:port1"
# 例2: 単一のノードに直接接続（セカンダリノードでも構いません）
# プライマリノードが分からない場合、レプリカセットの任意のノードに接続してみましょう。
# (例: localhost:27017)
# mongo --host "your_mongodb_host:your_port"
MongoDB Shellが起動したら、以下のコマンドを実行して、プライマリノードを特定します。
# MongoDB Shell 内で実行
rs.status()
# 出力結果の "stateStr" が "PRIMARY" となっているノードを探します。
# または、より簡潔にプライマリノードのアドレスを取得するには:
db.isMaster()
# 出力結果の "primary" フィールドにプライマリノードのホスト名とポートが表示されます。
手順2: プライマリノードに直接接続する
db.isMaster() で確認したプライマリノードのホスト名とポートを使用して、再度MongoDB Shellから接続し直します。
# PowerShellまたはコマンドプロンプトで実行
# 上記で確認したプライマリノードのホスト名とポートに置き換えてください。
# 例: mongo --host "mongodb0.example.com:27017"
mongo --host "primary_hostname:primary_port"
これで、プライマリノードに直接接続されました。この状態で書き込み操作を試してみてください。エラーが解消されているはずです。
手順3: アプリケーションの接続設定を見直す
もし、アプリケーションからエラーが発生している場合は、アプリケーションが使用しているMongoDBの接続文字列や設定を確認してください。
-
接続文字列の確認: アプリケーションが正しいプライマリノード（またはレプリカセット全体を自動的に検出できる形式）に接続するように設定されているか確認します。
推奨されるレプリカセットへの接続文字列は、複数のノードを指定し、
replicaSetパラメータを含めることで、ドライバーが自動的にプライマリを検出し、フェイルオーバー時にも自動的に再接続できるようになります。# 例: # mongodb://host1:27017,host2:27017,host3:27017/?replicaSet=myReplicaSet&readPreference=primary -
readPreferenceの設定: アプリケーションが書き込みを行う場合、readPreferenceが明示的にprimaryに設定されていることを確認してください。デフォルトではprimaryですが、誤ってsecondaryなどに設定されていると、書き込み時に「not master」エラーが発生する可能性があります。
3. not master が発生する主要な原因（複数）
「not master」エラーが発生する背景には、いくつかの主要な原因が考えられます。
-
アプリケーションがセカンダリノードに書き込みを実行しようとしている:
これが最も一般的な原因です。アプリケーションの接続設定やロジックが、プライマリノードではないセカンダリノードを指していたり、リードレプリカに書き込みを行おうとしている場合に発生します。 -
レプリカセットが一時的にプライマリノードを失っている（選挙中、またはダウンしている）:
プライマリノードが何らかの理由で利用できなくなった場合（クラッシュ、ネットワーク障害、シャットダウンなど）、レプリカセットは新しいプライマリを選出するために「選挙（election）」プロセスを開始します。この選挙期間中は、どのノードもプライマリではないため、一時的にすべての書き込み操作が「not master」エラーとなります。 -
接続文字列が古くなっている、または正しくない:
レプリカセットの構成が変更された（例えば、プライマリノードのIPアドレスやホスト名が変わった）にもかかわらず、アプリケーションの接続文字列が更新されていない場合に発生することがあります。 -
ネットワークの問題でノード間の通信ができない:
レプリカセット内のノード間でネットワーク通信が不安定だったり、ファイアウォールによってブロックされていたりすると、プライマリノードの選出がうまくいかなかったり、アプリケーションがプライマリノードを正しく認識できなかったりすることがあります。
4. MongoDB (Replica Set)で恒久的に再発を防ぐには
「not master」エラーの再発を防ぐためには、以下の点に注意してMongoDBレプリカセットを運用することが重要です。
4.1. アプリケーションの接続設定のベストプラクティス
-
replicaSetオプションの使用:
MongoDBのドライバーは、接続文字列にreplicaSetパラメータを含めることで、レプリカセットの構成を自動的に検出し、プライマリノードを特定する賢い機能を持っています。これにより、プライマリが変更された場合でも、アプリケーションが自動的に新しいプライマリに接続し直すことができます。mongodb://host1:27017,host2:27017,host3:27017/?replicaSet=yourReplicaSet上記のように複数のホストを指定することで、いずれかのノードがダウンしても、他のノードを通じてレプリカセット全体を認識し、適切なプライマリに接続できます。
-
readPreference=primaryの明示的な設定（書き込み時）:
書き込み操作を行う場合は、明示的にreadPreference=primaryを設定することをお勧めします。これにより、誤ってセカンダリに書き込もうとする試みを防ぎます。多くのドライバーでは書き込み操作のデフォルトがprimaryですが、設定を見直す際は確認してください。
4.2. レプリカセットの監視と健全性の維持
-
定期的なステータス確認:
定期的にrs.status()コマンドを実行し、レプリカセットのすべてのメンバーが正常に動作しているか、プライマリが正しく選出されているかを確認する習慣をつけましょう。 -
監視ツールの導入:
MongoDB Atlas (マネージドサービス) や、Prometheus + Grafana といった監視ツールを導入することで、レプリカセットの状態（ノードの稼働状況、レプリケーション遅延、選挙の発生など）をリアルタイムで監視し、問題発生時に迅速に対応できるようになります。 -
ネットワークの安定性確保:
レプリカセット内のノード間、およびアプリケーションとMongoDBノード間のネットワーク接続が安定していることを確認してください。ファイアウォールの設定も見直し、必要なポートが適切に開かれていることを確認します。
4.3. 障害発生時の自動復旧プロセスの理解
レプリカセットは、プライマリノードに障害が発生した場合、自動的に新しいプライマリノードを選出し、サービスの継続性を図ります（自動フェイルオーバー）。このプロセスには数秒から数十秒かかることがあり、この間は書き込み操作が一時的に停止します。この挙動を理解し、アプリケーション側で一時的なエラーを許容する（リトライロジックを実装するなど）設計を検討することも重要です。
これらの対策を講じることで、「not master」エラーの発生を大幅に減らし、安定したMongoDBレプリカセット運用を実現できます。