新しいシャード (レプリカ セット) を既存のシャード クラスターに追加するとどうなるかを理解しようとしています。これらの新しいメンバーを追加すると、使用可能な新しいシャード メンバーがあることがわかり、Mongo はチャンクの再配置を開始して、新しいメンバーを正しく利用できるようにしますか? これが起こると、あなたにどのような影響がありますか？いつものように、好ましくないパフォーマンス数値が表示され始めたらすぐにこれらのメンバーを追加してみることをお勧めします (他のチューニング オプションが役に立たない場合)。
クラスターが既に存在する場合にシャードを追加するとどうなるかをよりよく理解したいと思っただけです。
ありがとう、
S
シャードを既存のクラスターに追加すると、シャードされたコレクションごとにチャンク数が最も少ないシャードが自動的に作成されます。つまり、バランスが取れるまで、(チャンクの数が最も多いシャードからの) 移行のデフォルトのターゲットになります。ただし、各シャード プライマリ (移行を担当する) は、一度に 1 つの移行にしか参加できません。そのため、特に負荷がかかっている場合は、バランスを取るのに時間がかかります。
移行自体に関しては、現在のクラスターで既に移行が見られるため、その影響を判断する方法です。ログで最近の移行を表示するか、変更ログ (最新の移行/分割などを含む 10 MB の上限付きコレクション) を確認できます。
// connect to a mongos, switch to the config DB
use config
// look at the changelog
db.changelog.find()
どのような操作が行われるかという点では、チャンクを移動するには:
ステップ 3 は削除であり、ソース シャードでの書き込みロックが必要ですが、非常に高速である必要があります。ドキュメントは移行によって既にメモリ内にあります。
移行の頻度を上げることのもう 1 つの影響は、シャード バージョンがより頻繁に更新されることです。特に、メジャー シャード バージョンが更新されます (チャンクからシャードへのマッピングが最新になるようにするため)。
つまり、設定を更新してシャード バージョンを更新する必要がある mongos に関するメッセージがログに記録されます。Map/Reduce や findAndModify などの長時間実行される操作を開始する前に、 flushRouterConfig コマンドを実行することもお勧めします。
シャードの使用率が低い期間がある場合、移行がより迅速に行われることがわかります。また、重大な影響に気付いた場合は、バランサー ウィンドウオプションを使用して、特定の時間にのみバランシングを実行することを検討することもできます。
いつものように、不利なパフォーマンスの数値が表示され始めたらすぐに、これらのメンバーを追加してみてください。
トラフィックの増加を見越してシャードを追加したいのは私の経験です。特にシャードの数が少ない場合（<6程度）。新しいノードにデータを移行すると、既存のノードのIOが増加し、ネットワークトラフィックも増加します。
したがって、すでにIOの問題が発生している場合は、シャードを追加するとさらに悪化します。移行を「ベビーシッター」にするか、バランサーウィンドウオプションを使用することになります。実際、バランサーウィンドウオプションの存在は、バランシングプロセスの強度について何かを教えてくれるはずです。
これが起こったとき、あなたにどのような影響がありますか？
ここでの他の異常な副作用は、通常はメモリにないデータがメモリに引き込まれる可能性があることです。たとえば、1日のほとんど手つかずのままの履歴データがある場合、クライアントがアクティブに読み取っていなくても、データを取り込んで移動することができます。
繰り返しますが、これはIOと上記の私のコメントに結びつきます。
これらの新しいメンバーを追加すると、利用可能な新しいシャードメンバーがあることがわかり、Mongoはチャンクの再配置を開始します...
これは、シャーディングされ、シャードキーを持つコレクションでのみ発生することに注意してください。シャーディングされていないコレクションはまったく移動しません。これは、不明な理由でトラフィックが1つのシャードに蓄積し始めるまで、レーダーの下を飛ぶことがあります。
シャーディングされていないデータの場合、シャードが期待どおりに動作するように、データを別のレプリカセットに保持することをお勧めします。