どのデータベースでも、クライアントからのすべての要求の負荷分散は、スケーラビリティを確保するための重要で基本的なメカニズムです。適切な負荷分散ソリューションは、すべてのクライアント要求をすべてのデータベースリソースに均等に分散します。データベースクラスタが適切な負荷分散ソリューションで保護されていない場合、データベースは増大するトラフィック負荷を処理できません。
幸い、MongoDBは、シャーディングによる水平スケーリングをサポートすることで、高トラフィックの負荷分散をサポートします。シャーディングを使用して、コレクションのデータを複数のサーバーに分散できます。新しいサーバー/マシンをクラスターに追加して、データベースのトラフィックの増加を処理することもできます。このガイドに従って、MongoDBレプリカクラスターをシャーディングクラスターに変換できます。
この記事では、MongoDBシャードクラスターで実行されるバランサープロセスの動作と、その動作を変更する方法について学習します。 MongoDBバランサープロセスは、コレクションをシャード全体に均等に分散します。たとえば、クラスターの1つのシャードにシャードコレクションのチャンクが多すぎる場合、その特定のシャードは他のシャードと比較してより多くのトラフィックを受信できます。したがって、バランサープロセスは、シャード全体でコレクションのチャンクのバランスを適切に取ります。ほとんどのMongoDBデプロイメントでは、バランサープロセスのデフォルト構成で通常の操作に十分です。ただし、状況によっては、データベース管理者がこのプロセスのデフォルトの動作を変更したい場合があります。アプリケーションレベルのニーズや運用要件に合わせてバランサープロセスのデフォルトの動作を変更する場合は、このガイドに従うことができます。
バランサーのプロセスの状態とステータスに関する情報を取得するために、いくつかの基本的なコマンドから始めましょう。
このコマンドは、バランサーが有効になっているか、実行が許可されているかどうかを確認します。バランサープロセスが実行されていない場合、このコマンドはfalseを返します。これは、バランサープロセスが実行されているかどうかをチェックしません。
sh.getBalancerState()バランサーがデフォルトで有効になっていない場合は、次のコマンドを実行して有効にできます。このコマンドはバランサープロセスを開始しませんが、プロセスを有効にし、次回バランサープロセスを実行するときにチャンクバランシングがブロックされないようにします。
sh.enableBalancing(<collection_name/namespace>)バランサープロセスは、デフォルトでいつでも実行されます。したがって、特定の期間バランサープロセスを無効にする場合は、次のコマンドを使用できます。このコマンドを使用する理想的なシナリオの1つは、データベースのバックアップを作成する場合です。
sh.stopBalancer()バックアップを取る前に、バランサープロセスが停止していることを確認してください。データベースのバックアップ中にプロセスが有効になっていると、データベースのレプリカに一貫性がなくなる可能性があります。これは、バックアッププロセス中に、バランサープロセスが負荷分散のためにシャード間でいくつかのチャンクを移動するときに発生する可能性があります。
次のコマンドを使用して、コレクションの完全な名前空間をパラメーターとして指定することにより、特定のコレクションのバランシングを無効にすることもできます。
sh.disableBalancing("<db_name>.<collection_name>")このコマンドは、バランサープロセスが実行されているかどうかを確認します。また、シャーディングチャンクをアクティブに管理しているかどうかもチェックします。プロセスが実行中の場合はtrueを返し、そうでない場合はfalseを返します。
sh.isBalancerRunning()デフォルトでは、MongoDBシャードクラスターのチャンクサイズは64MBです。ほとんどのシナリオでは、これはシャーディングされたチャンクを移行または分割するのに十分です。ただし、通常の移行プロセスには、ハードウェアが処理できる以上のI/O操作が含まれない場合があります。このような状況では、チャンクのサイズを小さくすることをお勧めします。これを行うには、次の一連のコマンドを実行します。
use config
db.settings.save( { _id:"chunksize", value: <sizeInMB> } )シャードクラスターのデフォルトのチャンクサイズを変更する場合は、次の点に注意してください
- チャンクサイズは、1〜1024MBの間でのみ指定できます
- 自動分割は、挿入または更新時にのみ発生します
- チャンクサイズを小さくすると、分割プロセスの時間が長くなります。
データベースのサイズが大きい場合、バランシングまたは移行プロセスがデータベースの全体的なパフォーマンスに影響を与える可能性があります。したがって、データベースの負荷が非常に少ない特定の時間枠の間にバランシングプロセスをスケジュールすることをお勧めします。次のコマンドを使用して、バランサープロセスを実行する時間枠を設定できます。
use config
db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } }, true )次のコマンドは、バランシングプロセスを実行するための時間枠を午前1時から午前5時までに設定します。
db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "01:00", stop : "05:00" } } }, true )次のコマンドを実行して、既存のバランシングプロセスの時間枠を削除することもできます。
db.settings.update({ _id : "balancer" }, { $unset : { activeWindow : true } })上記のコマンドとは別に、_secondaryThrottleパラメーターを使用して、チャンク移行プロセスの実行中にレプリケーションの動作を変更することもできます。また、moveChunkコマンドで_waitForDeleteプロパティを使用して、新しいチャンク移行フェーズを開始する前に、現在の移行の削除フェーズを待機するようにバランシングプロセスに指示できます。
うまくいけば、MongoDBバランサープロセスのデフォルトの動作を変更するときに必要なのはこれだけです。バランシングは、MongoDBシャードクラスターの非常に重要な側面です。したがって、バランシングプロセスについて詳しく知っていると、ニーズやユースケースに応じてバランサープロセスのデフォルトの動作を非常に簡単に変更できます。