シャーディングされたクラスターでは、チャンクの移行が停止したり、1 つ以上のチャンクが ジャンボ になったりする状況が発生する可能性があります。こうした場合、バランサーはシャード間でデータを均等に分散できなくなります。そのため、リソース使用率が不均等になり、クラスターのパフォーマンスが低下する恐れがあります。
このページでは、チャンク移行と ジャンボ チャンクが停止する一般的な原因と、これらの条件を診断および解決する手順について説明します。以下の手順を完了しても問題が解決しない場合は、テクニカル サポートにお問い合わせください。
前提条件チェック
クラスターが停止した移行または ジャンボ チャンクの影響を受けているかどうかを確認します。
バランサーの状態の確認
mongosインスタンスから、次を実行します。
sh.getBalancerState()
このメソッドは true を返しますが、データ分散が不均一な場合は、追加の調査が必要です。
また、詳細なバランサー情報を確認することもできます。
db.adminCommand({ balancerStatus: 1 })
チャンク分散の確認
シャード間でのチャンクの分散を確認するには、次のコマンドを実行します。
sh.status(true)
次の項目を探します。
シャードあたりのチャンク数における差
としてマークされたチャンク
jumbo
注意
jumbo としてマークされたチャンクは、サイズが分裂れるか、または縮小されるまで、バランサーによって移行できません。
ログ メッセージの確認
コンフィギュレーションサーバー ログ
バランシングまたは チャンクの移行に関連するエントリについて、コンフィギュレーションサーバー のログを確認します。次の内容を示すメッセージを探します。
移行の再試行
中止された移行
ジャンボとマークされたチャンク
移行コミットまたは削除フェーズ中の失敗
シャード ログ
シャード ノードで、以下のログを確認します。
ロック取得のタイムアウト
移行に影響するレプリケーションラグ
ディスク容量のエラー
移行ステップの失敗
一般的な問題と解決策
ジャンボチャンクは移行を防止します
チャンクは、設定されたチャンク サイズを超えると ジャンボ になり、自動的に分裂できません。
ジャンボチャンクの特定
mongos から:
sh.status(true)
jumbo というラベルの付いたチャンクを見つけます。
ジャンボチャンクの解決
分割可能な チャンク には複数の一意のシャードキー値が含まれ、分裂できます。分割可能なジャンボチャンクを解決するには、手動で分裂。
sh.splitAt("database.collection", { shardKeyField: <value> })
必要に応じてバランサーを再起動します。
sh.startBalancer()
手動分割が適切なタイミングについては、「 シャードクラスタでのチャンクの分割 」を参照してください。
分割不可 のチャンクは、単一の一意のシャードキー値を表し、分裂できません。分割不可のジャンボチャンクを解決するには、以下の手順を行います。
refineCollectionShardKeyを使用してシャードキーを調整し、サフィックスフィールドを追加し、チャンクを分割可能にします。 「 分割されたチャンク 」を参照してください。より均等に分散されたシャードキーを使用してコレクションを再シャーディングします。 「 コレクションの再シャーディング 」を参照してください。
ジャンボチャンクの解決の詳細については、「 jumboフラグのクリア 」を参照してください。
非効果的なシャードキー分散
シャードキーの濃度が低い場合や、単調に増加するパターンに従っている場合、チャンクは不均等に大きくなり、バランシングに妨げられる可能性があります。
軽減するには:
コレクションで使用されるシャードキーパターン を確認します。
ほとんどの書き込みが狭いシャードキー範囲を対象にしているかどうかを判断してください。高頻度のシャードキー値によって書き込みが 1 つのシャードに集中する場合は、「 シャードキーのトラブルシューティング 」を参照してください。
より均等に分散されたシャードキーを使用してコレクションを再シャーディングすることを検討してください。
バランサーが無効または一時停止
バランサーが無効の場合、チャンク移行は行われません。
バランサーの状態を確認します。
sh.getBalancerState()
無効になっている場合は、有効にします。
sh.startBalancer()
進行中の操作による移行のブロック
長時間実行されている操作、インデックスビルド、または重い書き込みワークロードでは、チャンクの移行が遅延したりブロックされたりする可能性があります。
競合を減らすには、次の手順に従います。
実行時間が長い操作を特定します。
db.currentOp() 書込み (write) アクティビティが少ない期間中のスケジュール バランシング。
すべてのシャードで十分なディスク領域が利用可能であることを確認します。
注意
チャンクの移行には、データのクローンと削除フェーズが含まれます。ディスク容量が不足していたり、レプリケーションラグが大きい場合、これらのフェーズが遅れる可能性があります。
解決策を確認する
問題を解決した後、以下を行います。
チャンク移行が正常に完了しました。
jumboとしてマークされたままのチャンクはありません。シャード間での チャンク の分散がより均等になります。
バランサーはアクティブで安定したままです。
ディストリビューションを再確認します。
sh.status(true)
より多くのサポートのために収集する診断情報
問題が解決されない場合は、テクニカル サポートに連絡する前に以下を収集してください。
の出力
sh.status(true)の出力
db.adminCommand({ balancerStatus: 1 })関連するコンフィギュレーションサーバーログ
関連するシャード ログ
影響を受けるコレクションのシャードキーの定義
MongoDB バージョン
クラスタートポロジーの説明
シャードあたりのチャンク数とデータサイズの
sh.getShardedDataDistribution()の出力