シャーディングされたクラスターのトラブルシューティング
項目一覧
このページでは、 のシャーディングされたクラスターの配置をトラブルシューティングするための一般的な方法について説明します。
始める前に
MongoDB 8.0以降では、 directShardOperationsロールを使用して、シャードに対してコマンドを直接実行する必要があるメンテナンス操作を実行できます。
警告
directShardOperationsロールを使用して コマンドを実行すると、クラスターが正しく動作しなくなり、データが破損する可能性があります。 directShardOperationsロールは、メンテナンス目的で、または MongoDB サポートのガイダンスに必ず従う必要があります。 メンテナンス操作を実行したら、 directShardOperationsロールの使用を停止します。
アプリケーション サーバーまたは mongos インスタンスが使用不可になる
各アプリケーション サーバーに独自のmongosインスタンスがある場合、他のアプリケーション サーバーは引き続きデータベースにアクセスできます。 さらに、 mongosインスタンスは永続的な状態を維持せず、状態やデータを失うことなく再起動して使用できなくなる可能性があります。 mongosインスタンスが起動すると、構成データベースのコピーが取得され、クエリのルーティングを開始できます。
シャード レプリカセットで単一ノードが使用できなくなる
レプリカセットはシャードに高可用性を提供します。 使用できないmongodがプライマリである場合、レプリカセットは新しいプライマリを選択します。 使用できないmongodがセカンダリであり、切断された場合、プライマリとセカンダリはすべてのデータを保持し続けます。 3 つのノードからなるレプリカセットでは、セットの 1 つのノードに致命的な障害が発生した場合でも、他の 2 つのノードにはデータの完全なコピーが保持されます。 [1]
可用性の中断や障害は常に調査してください。 システムが回復不能な場合は、それを交換し、可能な限り迅速にレプリカセットの新しいノードを作成して、失われた冗長性を置き換えます。
| [1] | 現在の oplog エントリがあるときに使用できないセカンダリが使用可能になった場合は、通常のレプリケーション プロセスを使用してセットの最新の状態に追いつくことができます。そうでない場合は、最初の同期を実行する必要があります。 |
シャードのすべてのノードが使用できなくなる
シャーディングされたクラスターでは、 mongodおよびmongosインスタンスがシャーディングされたクラスター内のレプリカセットを監視します（例：シャード レプリカセット、コンフィギュレーションサーバー レプリカセット）。
レプリカセット シャードのすべてのノードが使用できない場合、そのシャードに保持されているすべてのデータは使用できなくなります。 ただし、他のすべてのシャード上のデータは引き続き使用でき、他のシャードに対するデータの読み取りと書込みは可能です。 ただし、アプリケーションは部分的な結果を処理できる必要があり、中断の原因を調べて、シャードをできるだけ早く回復するよう試みる必要があります。
コンフィギュレーションサーバーのレプリカセット ノードが使用できなくなる
レプリカセットは、コンフィギュレーションサーバーに高可用性を提供します。 使用できないコンフィギュレーションサーバーがプライマリである場合、レプリカセットは新しいプライマリを選択します。
レプリカセット コンフィギュレーションサーバーがプライマリを失い、プライマリを選出できない場合、クラスターのメタデータは読み取り専用になります。 シャードからのデータの読み取りと書き込みは引き続き可能ですが、プライマリが使用可能になるまで、チャンクの移行やチャンクの分裂は行われません。
注意
レプリカセットのノードを 2 つのデータセンターに分散させると、1 つのデータセンターよりもメリットがあります。2つのデータセンターに分散させた場合、
データセンターの 1 つがダウンしても、1 つのデータセンターのみを利用する場合とは異なり、データは引き続き読み取り可能です。
少数のノードを含むデータセンターがダウンした場合でも、レプリカセットは読み取り操作だけでなく書込み操作も引き続き実行できます。
ただしノードの大多数を含むデータセンターがダウンすると、レプリカセットは読み取り専用になります。
可能であれば、ノードは少なくとも 3 つのデータセンターに分散させます。コンフィギュレーションサーバー レプリカセット （CSRS）の場合、ベストプラクティスはノードを 3 つ（ノード数によってはそれ以上）のセンターに分散させることです。3 つのデータセンターを利用するにはコストが高すぎる場合の選択肢の 1 つは、会社のポリシー上可能であれば、データを含むノードを 2 つのデータセンターに均等に分散し、残りのノードをクラウドに保存することです。
古い設定データが原因でカーソルが失敗
クエリは、1 つ以上のmongosインスタンスがコンフィギュレーションデータベースからクラスターのメタデータのキャッシュをまだ更新していない場合、次の警告を返します。
could not initialize cursor across all shards because : stale config detected
この警告はアプリケーションに伝達されないようにしてください。 すべてのmongosインスタンスがキャッシュを更新するまで、警告が繰り返されます。 インスタンスにキャッシュの更新を強制するには、 flushRouterConfigコマンドを実行します。
シャードキー
シャードキーのトラブルシューティングについては、 「 シャードキーのトラブルシューティング 」を参照してください。
クラスターの可用性
クラスターの可用性を確保するには、次の手順に従います。
各シャードはレプリカセットである必要があります。特定の
mongodインスタンスが失敗した場合、レプリカセット ノードは別のシャードをプライマリとして選択し、操作を続行します。 ただし、シャード全体がアクセスできなくなったり、何らかの理由で失敗した場合は、そのデータは利用できなくなります。シャードキーにより、
mongosがほとんどの操作を単一のシャードに分離できるようになります。 操作が単一のシャードで処理できる場合、単一のシャードに障害が発生しても、一部のデータは使用できなくなります。 操作がクエリのすべてのシャードにアクセスする必要がある場合、1 つのシャードに障害が発生すると、クラスター全体が使用できなくなります。
Config Database String Error
コンフィギュレーションサーバーは レプリカセット として配置する必要があります。 シャーディングされたクラスターのmongosインスタンスで指定するコンフィギュレーションサーバー レプリカセット名は同じにする必要がありますが、レプリカセットのノードのホスト名とポートにはそれぞれ異なった指定ができます。
コンフィギュレーションサーバーに 3 つのミラーリングされたmongodインスタンスのトポロジーを使用する MongoDB のシャーディングされたクラスターの以前のバージョンでは、シャーディングされたクラスター内のmongosインスタンスは同一のconfigDB string を指定する必要があります。
コンフィギュレーションサーバーを移動する際のダウンタイムを回避する
CNAME を使用してクラスターにコンフィギュレーションサーバーを識別させると、ダウンタイムなしでコンフィギュレーションサーバーの名前や番号を変更できます。
moveChunk commit failed エラー
チャンクの移行の終了時に、シャードは コンフィギュレーションデータベースに接続して、クラスター メタデータ内のチャンクのレコードを更新する必要があります。 シャードが コンフィギュレーションデータベースへの接続に失敗した場合、MongoDB は次のエラーを報告します。
ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"
こうした場合、シャードのレプリカセットのプライマリノードは終了してデータの一貫性を保護します。 セカンダリノードが コンフィギュレーションデータベース にアクセスできる場合、選挙後にシャード上のデータに再度アクセスできるようになります。
ユーザーは、チャンク移行の失敗を自分で解決する必要があります。 この問題が発生した場合は、 MongoDB CommunityまたはMongoDB サポートに問い合わせてこの問題に対処してください。
一貫性のないシャーディング メタデータ
MongoDB 7.0 以降では、 checkMetadataConsistencyコマンドを使用して、MongoDB の以前のリリースのバグが原因でシャーディング メタデータの不整合や破損をチェックできます。
シャーディング メタデータにおける不整合は、次のようなケースに起因します。
過去の DDL 操作によりデータが破損した可能性がある MongoDB の 5.0 より前のリリースからアップグレードされたクラスター。
手動介入。たとえば、コンフィギュレーションデータベースの操作や
mongosをバイパスしてシャードに直接書込むなど。アップグレード手順やダウングレード手順などのメンテナンス操作。
こうした不整合により、誤ったクエリ結果やデータが失われる可能性があります。
シャーディング メタデータの不整合を確認するには、 checkMetadataConsistencyコマンドを実行します。
db.runCommand( { checkMetadataConsistency: 1 } )
{ cursor: { id: Long("0"), ns: "test.$cmd.aggregate", firstBatch: [ { type: "MisplacedCollection", description: "Unsharded collection found on shard different from database primary shard", details: { namespace: "test.authors", shard: "shard02", localUUID: new UUID("1ad56770-61e2-48e9-83c6-8ecefe73cfc4") } } ], }, ok: 1 }
checkMetadataConsistencyコマンドによって返されたドキュメントは、クラスターのシャーディング メタデータにおいて MongoDB によって識別された不整合を示しています。
checkMetadataConsistencyコマンドによって返される不整合ドキュメントの詳細については、「不整合のタイプ 」を参照してください。