このセクションでは、レプリカセットのデプロイをトラブルシューティングするための一般的な方法について説明します。
レプリカセットのステータス確認
To display the current state of the replica set and current state of each member, run the rs.status() method in a mongosh session that is connected to the replica set's primary. For descriptions of the information displayed by rs.status(), see replSetGetStatus (database command).
注意
rs.status() メソッドは、replSetGetStatus データベース コマンドのラッパーです。
レプリケーションラグの確認
レプリケーションラグとは、プライマリでの操作から、その操作が oplog からセカンダリに適用されるまでの遅延時間のことです。レプリケーションラグは重大な問題となり、MongoDB レプリカセットのデプロイに深刻な影響を与える可能性があります。また、レプリケーションラグが長くなりすぎると、「遅延した」ノードはすぐにプライマリになる資格を失い、分散された読み取り操作が一貫性を失う可能性が高まります。
現状のレプリケーションラグの長さを確認するには
In a
mongoshsession that is connected to the primary, call thers.printSecondaryReplicationInfo()method.各ノードの
syncedTo値を返します。これは、次の例に示すように、直近の oplog エントリがセカンダリに書き込まれた時刻を示します。source: m1.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary source: m2.example.net:27017 syncedTo: Thu Apr 10 2014 10:27:47 GMT-0400 (EDT) 0 secs (0 hrs) behind the primary プライマリの非アクティブ期間が
members[n].secondaryDelaySecsの値より大きい場合、遅延ノードはプライマリより0秒遅れて表示されることがあります。注意
rs.status()メソッドは、replSetGetStatusデータベース コマンドのラッパーです。スロークエリログメッセージの
totalOplogSlotDurationMicrosは、書き込み操作がストレージエンジンの書き込みをコミットするためのコミットタイムスタンプを取得してから、実際にコミットするまでの時間を示しています。mongodは並列書き込みをサポートします。ただし、書込み (write) 操作はコミット タイムスタンプとともに任意の順序でコミットされます。例
例えば、次のコミット タイムスタンプを持つ書き込みについて考えてみましょう。
書込み A とタイムスタンプ 1
書込み B とタイムスタンプ 2
書込み C とタイムスタンプ 3
書込み B が タイムスタンプ 2 で最初にコミットするとします。レプリケーションは書込み A がコミットするまで一時停止します。レプリケーションでレプリカセットのセカンダリに oplog をコピーするには、書込み A の oplog エントリとタイムスタンプ 1 が必要なためです。
Cloud Manager および Ops Manager で使用可能な Replication Lag グラフで、oplog 時間値がゼロ以外または増加しているかどうかを確認して、レプリケーションの速度を監視します。
レプリケーションラグの原因
レプリケーションラグの主な原因
ネットワーク レイテンシ
セットのメンバー間のネットワークルートに、パケットロスやネットワークルーティングの問題がないことを確認します。
pingなどのツールを使用してセットメンバー間のレイテンシをテストし、tracerouteを使用してネットワーク エンドポイント間のパケットのルーティングを明らかにします。ディスクのスループット
セカンダリのファイル システムとディスク デバイスが、プライマリほど速くデータをディスクにフラッシュできない場合、セカンダリは状態を維持するのが困難になります。ディスクに関連する問題は、仮想化インスタンスなどのマルチテナント システムでは非常に一般的です。また、システムが IP ネットワーク経由でディスク デバイスにアクセスする場合（Amazon の EBS システムなど）、一時的な問題である可能性があります。
iostatやvmstatなどディスクの状態を評価するには、システムレベルのツールを使用します。同時実行性
セカンダリでのレプリケーションが、プライマリで長時間実行されている操作によってブロックされる場合があります。最良の結果を得るには、セカンダリにレプリケーションの確認を要求するように書込み保証（write concern）を設定します。これにより、レプリケーションが書込み（write）負荷に追いつかない場合に、書込み操作が完了前に結果を返さないよう防げます。
また、データベースプロファイラーを使用して、レイテンシの発生に関連する低速クエリや長時間実行操作がないかを確認できます。
適切な書込み保証（write concern）
特に
unacknowledged write concernを使用して、プライマリへの大量の書き込みを必要とする大規模なデータ取り込みまたは一括ロード操作を実行していると、セカンダリは十分な速度で oplog を読み取れず、変更に対応できなくなります。これを防ぐために、100、1,000、など、適切なインターバルごとに書き込み確認（書き込み保証 / write concern）をリクエストして、セカンダリがプライマリに追いつく機会を設けるようにします。
詳しくは、以下を参照してください。
フロー制御
MongoDB 4.2 以降、majority committed の遅延を設定可能な最大値 flowControlTargetLagSeconds 以下に抑えることを目的として、プライマリが書き込み (write) を適用する速度を管理者が制限することができます。
デフォルトのフロー制御は、enabled です。
フロー制御が有効になっている場合、遅延が flowControlTargetLagSeconds に近づくと、プライマリでの書き込み (write) は、書き込みを適用するためのロックを行う前にチケットを取得する必要があります。フロー制御メカニズムでは、1秒あたりに発行されるチケットの数を制限することで、遅延を目標値以下に保とうとします。
セカンダリが応答しない場合など、フロー制御を行うのに十分な負荷がレプリカセットに与えられなくても、レプリケーションラグが発生する可能性があります。
フロー制御のステータスを表示するには、プライマリで次のコマンドを実行します。
rs.printSecondaryReplicationInfo()メソッドを実行して、遅延しているノードがないかどうかを確認します。rs.printSecondaryReplicationInfo() 出力例:
source: 192.0.2.2:27017 { syncedTo: 'Mon Jan 31 2022 18:58:50 GMT+0000 (Coordinated Universal Time)', replLag: '0 secs (0 hrs) behind the primary ' } --- source: 192.0.2.3:27017 { syncedTo: 'Mon Jan 31 2022 18:58:05 GMT+0000 (Coordinated Universal Time)', replLag: '45 secs (0 hrs) behind the primary ' } serverStatusコマンドを実行し、flowControl.isLagged値を使用してレプリカセットがフロー制御を実行しているかどうかを判断します。db.runCommand( { serverStatus: 1 } ).flowControl.isLagged 出力例:
false フロー制御が実行されていなかった場合、セカンダリを調査して、レプリケーションラグの原因を特定します。原因としては、ハードウェア、ネットワーク、アプリケーションの制限などが挙げられます。
フロー制御に関する統計について詳しくは、以下を参照してください。
Oplog エントリの低速適用
replica setのセカンダリ メンバーは、適用に低速操作しきい値よりも長い時間がかかるoplogをログに記録するようになりました。 これらの遅い oplog メッセージ:
ログは、テキスト
applied op: <oplog entry> took <num>msを含むREPLコンポーネントの下にあります。ログレベルに依存しない（システムレベルでもコンポーネントレベルでも）
プロファイル レベルに依存しないでください。
slowOpSampleRateの影響を受けます。
プロファイラーは遅い oplog エントリをキャプチャしません。
全ノード間の接続テスト
レプリケーションをサポートするには、レプリカセットの全ノードが、同じレプリカセット内の他のすべてのノードに接続できる必要があります。接続が両方向であることを常に確認してください。ネットワーク トポロジーとファイアウォールの構成により、正常かつ必要な接続が妨げられ、レプリケーションがブロックされる可能性があります。
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
MongoDB バイナリ（mongod と mongos）は、デフォルトで localhost にバインドされます。バイナリに net.ipv6 構成ファイルや --ipv6 コマンド ライン オプションが設定されている場合、バイナリはローカルホストの IPv6 アドレスに追加でバインドされます。
By default mongod and mongos that are bound to localhost only accept connections from clients that are running on the same computer. This binding behavior includes mongosh and other members of your replica set or sharded cluster. Remote clients cannot connect to binaries that are bound only to localhost.
デフォルトのバインドをオーバーライドして、他の IP アドレスにバインドするには、net.bindIp 構成ファイル設定や --bind_ip コマンド ライン オプションを使用して、ホスト名または IP アドレスのリストを指定します。
警告
MongDB5.0 以降、 IPアドレスのみが設定されている分裂ホライゾン DNS ノードはスタートアップの検証に失敗し、エラーを報告します。 を参照してください。disableSplitHorizonIPCheck
たとえば、次の mongod インスタンスは、IP アドレス 198.51.100.1 に関連付けられているローカルホストとホスト名 My-Example-Associated-Hostname の両方にバインドします。
mongod --bind_ip localhost,My-Example-Associated-Hostname
このインスタンスに接続するには、リモート クライアントはホスト名またはそれに関連付けられた IP アドレス198.51.100.1を指定する必要があります。
mongosh --host My-Example-Associated-Hostname mongosh --host 198.51.100.1
次のネットワークの双方向テストの例について考えてみましょう。
例
以下の 3 つの異なるノードで動作するレプリカセットがあるとします。
m1.example.netm2.example.netm3.example.net
すべてのノードで、デフォルトのポート 27017 が使用されます。
m1.example.netから他のホストへの接続をテストするには、次の操作をm1.example.netで実行します。mongosh --host m2.example.net --port 27017 mongosh --host m3.example.net --port 27017 m2.example.netから他の 2 つのホストへの接続をテストするには、次のような操作をm2.example.netから実行します。mongosh --host m1.example.net --port 27017 mongosh --host m3.example.net --port 27017 これで、
m2.example.netとm1.example.net間の接続を両方向でテストできました。m3.example.netから他の 2 つのホストへの接続をテストするには、次のような操作をm3.example.netから実行します。mongosh --host m1.example.net --port 27017 mongosh --host m2.example.net --port 27017
どの方向にも接続できなかった場合、ネットワークとファイアウォールの構成を確認し、これらの接続を許可するように環境を再構成してください。
複数のセカンダリを再起動するときのソケット例外
レプリカセットのノードを再起動するときは、レプリカセットがメンテナンス中にプライマリを選択できることを確認してください。これは、レプリカセットの members[n].votes の過半数が利用可能であることを保証することを意味します。
セットのアクティブ メンバーが過半数を形成できなくなると、セットのプライマリは降格してセカンダリになります。プライマリが降格しても、クライアント接続は閉じられません。
ノードによって新しいプライマリが選出されるまで、クライアントはレプリカセットに書き込みを行えません。
例
3 つのノードがそれぞれ 1 票を持つレプリカセットの場合、少なくとも 2 つのノードが相互接続できれば、そのセットでプライマリを選出できます。2 つのセカンダリを同時に再起動すると、プライマリが降格してセカンダリになります。少なくとも別のセカンダリが使用可能になるまで、つまり再起動したセカンダリのうち少なくとも 1 つが使用可能になるまで、そのセットにはプライマリがなく、新しいプライマリの選出もできません。
投票について詳しくは、「レプリカ セットの選挙」を参照してください。接続エラーの関連情報については、「TCP keepalive 時間が MongoDB デプロイに及ぼす影響」を参照してください。
oplog のサイズ確認
oplog が大きいほど、レプリカセットの遅延に対する許容度が高まり、セットの回復力が高まります。
To check the size of the oplog for a given replica set member, connect to the member in mongosh and run the rs.printReplicationInfo() method.
出力には、oplog のサイズと、oplog に含まれる操作の日付範囲が表示されます。以下の例では、oplog は約 10MB で、約 26 時間（94,400 秒）の操作を格納できます。
configured oplog size: 10.10546875MB log length start to end: 94400 (26.22hrs) oplog first event time: Mon Mar 19 2012 13:50:38 GMT-0400 (EDT) oplog last event time: Wed Oct 03 2012 14:59:10 GMT-0400 (EDT) now: Wed Oct 03 2012 15:00:21 GMT-0400 (EDT)
oplogは、予想しうる最長のセカンダリのダウンタイムの間、すべてのトランザクションを保持できる長さである必要があります。[1] 少なくとも、oplog で 24 時間分の操作を保持できる必要がありますが、ユーザーの多くは、72 時間または 1 週間分の操作の保持を好みます。
oplog のサイズが操作に与える影響について詳しくは、以下を参照してください。
注意
通常、すべてのノードで oplog を同じサイズに揃えます。oplog のサイズを変更する場合は、すべてのノードでサイズを変更します。
oplogサイズを変更するには、「自己管理型レプリカセット ノードのoplogサイズの変更」チュートリアルを参照してください。
| [1] | oplog は、 |