ClusterControlの最新リリースは、最も厄介なMongoDBタスクのいくつかをわずか15秒のジョブに変えます。クラスタをより細かく制御し、トポロジの変更を実行できるようにするための新機能が追加されました。
- MongoDBレプリカセットをシャーディングされたMongoDBクラスターに変換します
- シャードの追加と削除
- シャードされたMongoDBクラスターにシャードルーターを追加する
- ノードをステップダウンまたはフリーズします
- 新しいMongoDBアドバイザー
これらの追加機能については、以下で詳しく説明します。
MongoDBレプリカセットをシャーディングされたMongoDBクラスターに変換する
ほとんどのMongoDBユーザーは、データベースを格納するためにreplicaSetから始めるため、これは最も頻繁に使用されるタイプのクラスターです。スケーリングの問題が発生した場合は、セカンダリを追加するか、シャーディングによってスケールアウトすることで、このreplicaSetをスケーリングできます。既存のreplicaSetをシャードクラスターに変換できますが、これは長いプロセスであり、簡単にエラーが発生する可能性があります。 ClusterControlでは、このプロセスを自動化し、Configserver、シャードルーターを自動的に追加し、シャーディングを有効にしました。
レプリカセットをシャードクラスターに変換するには、アクションドロップダウンを使用してトリガーするだけです。
これにより、これをシャードに変換する方法に関する2段階のダイアログが開きます。最初のステップは、Configserverとシャードルーターを次の場所に展開する場所を定義することです。
2番目のステップは、データを保存する場所と、Configserverおよびシャードルーターに使用する構成ファイルです。
シャード移行ジョブが終了すると、クラスターの概要に、replicaSetインスタンスではなくシャードが表示されるようになりました。
シャードクラスターに変換した後、新しいシャードを追加できます。
シャーディングされたMongoDBクラスターにシャードを追加または削除する
シャードの追加
MongoDBシャードは技術的にはreplicaSetであるため、新しいシャードを追加するには、新しいreplicaSetのデプロイも必要です。 ClusterControl内で、最初に新しいreplicaSetをデプロイしてから、それをシャーディングされたクラスターに追加します。
ClusterControl UIから、アクションドロップダウンから開いた2ステップのウィザードを使用して新しいシャードを簡単に追加できます。
ここで、新しいシャードのトポロジを定義できます。
新しいシャードがクラスターに追加されると、MongoDBシャードルーターが新しいチャンクの割り当てを開始し、バランサーがすべてのシャードのすべてのチャンクのバランスを自動的に取ります。
シャードの削除
シャード自体を削除する前にデータを他のシャードに移動する必要があるため、シャードを削除することは、シャードを追加するよりも少し難しいです。すべてのシャードでシャーディングされたすべてのデータについて、これはMongoDBバランサーによって実行されるジョブになります。
ただし、このシャードをプライマリシャードとして割り当てられた、シャード化されていないデータベース/コレクションは、別のシャードに移動して、新しいプライマリシャードにする必要があります。このプロセスでは、MongoDBは、これらの非シャーディングデータベース/コレクションの移動先を知る必要があります。
ClusterControlでは、アクションドロップダウンを使用してそれらを簡単に削除できます：
これにより、削除するシャードと、プライマリデータベースを移行するシャードを選択できます。
シャードを削除するジョブは、前述と同様のアクションを実行します。プライマリデータベースを指定されたシャードに移動し、バランサーを有効にしてから、シャードからすべてのデータを移動するのを待ちます。
すべてのデータが削除されると、UIからシャードが削除されます。
追加のMongoDBシャードルーターの追加
MongoDBシャードクラスターを使用してアプリケーションのスケールアウトを開始すると、追加のシャードルーターが必要になる場合があります。
追加のMongoDBシャードルーターの追加は、ClusterControlを使用した非常に簡単なプロセスであり、アクションドロップダウンから[ノードの追加]ダイアログを開くだけです。
これにより、新しいシャードルーターがクラスターに追加されます。ルーターに適切なデフォルトポート（27017）を設定することを忘れないでください。
サーバーのステップダウン
レプリカセットのプライマリノードでメンテナンスを実行する場合は、オフラインにする前に、最初に適切な方法で「ステップダウン」することをお勧めします。プライマリをステップダウンすると、基本的に、ホストがプライマリでなくなり、セカンダリになり、設定された秒数の間、プライマリになる資格がなくなります。投票権を持つMongoDBreplicaSetのノードは、設定された秒数の間、ステップダウンされたプライマリを除外した新しいプライマリを選出します。
ClusterControlでは、ノードページのアクションとしてステップダウン機能を追加しました。ステップダウンするには、ドロップダウンからアクションとしてこれを選択するだけです：
ステップダウンの秒数を設定して確認すると、プライマリがステップダウンし、新しいプライマリが選出されます。
ノードをフリーズする
この機能はステップダウンコマンドに似ています。これにより、特定のノードが設定された秒数の間プライマリになる資格がなくなります。これは、プライマリをステップダウンするときに1つ以上のセカンダリノードがプライマリになるのを防ぎ、この方法で特定のノードを新しいプライマリにすることを強制できることを意味します。
ClusterControlでは、ノードページのアクションとしてノードのフリーズ機能を追加しました。ノードをフリーズするには、ドロップダウンからアクションとしてこれを選択するだけです：
秒数を設定して確認した後、ノードは設定された秒数の間、プライマリとして適格ではなくなります。
新しいMongoDBアドバイザー
アドバイザーは、特定のデータベースの問題に関するアドバイスを提供するミニプログラムです。 MongoDBに3つの新しいアドバイザーを追加しました。 1つ目はレプリケーションウィンドウを計算し、2つ目はレプリケーションウィンドウを監視し、3つ目はシャーディングされていないデータベース/コレクションをチェックします。
MongoDB Replication Lag Advisor
セカンダリを追加して読み取りをスケールアウトする場合は、レプリケーションの遅延を監視することが非常に重要です。 MongoDBは、これらのセカンダリがそれほど遅れていない場合にのみ、これらのセカンダリを使用します。セカンダリにレプリケーションの遅延がある場合、プライマリですでに上書きされている古いデータを提供するリスクがあります。
レプリケーションラグを確認するには、プライマリに接続し、replSetGetStatusコマンドを使用してこのデータを取得するだけで十分です。 MySQLとは異なり、プライマリはセカンダリのレプリケーションステータスを追跡します。
このチェックをClusterControlのアドバイザーに実装して、レプリケーションの遅延が常に監視されるようにしました。
MongoDBレプリケーションウィンドウアドバイザー
レプリケーションラグと同様に、レプリケーションウィンドウも同様に重要な指標です。ラグアドバイザは、セカンダリノードがプライマリ/マスターの背後にある秒数をすでに通知しています。 oplogのサイズには制限があるため、スレーブラグがあると次のリスクが発生します。
- ノードが大幅に遅れている場合、追いつくために必要なトランザクションがプライマリのoplogにないため、追いつくことができなくなる可能性があります。
- 遅れているセカンダリノードは、新しいプライマリのMongoDB選択ではあまり好まれません。すべてのセカンダリがレプリケーションで遅れている場合、問題が発生し、遅れが最も少ないものがプライマリになります。
- MongoDBを使用して読み取りをスケールアウトする場合、遅れているセカンダリはMongoDBドライバーにあまり好まれません。また、残りのセカンダリのワークロードが高くなります。
セカンダリノードが数分（または数時間）遅れる場合は、次のトランザクションがoplogから削除されるまでの残り時間を通知するアドバイザーがいると便利です。 oplogの最初のエントリと最後のエントリの時間差は、レプリケーションウィンドウと呼ばれます。このメトリックは、oplogから最初と最後のアイテムをフェッチし、それらのタイムスタンプの差を計算することで作成できます。
MongoDBシェルには、レプリケーションウィンドウを計算するために使用できる関数がすでにあります。ただし、この関数はコマンドラインシェルに組み込まれているため、コマンドラインシェルを使用しない外部接続にはこの組み込み関数はありません。そのため、レプリケーションウィンドウを監視し、事前に設定されたしきい値を超えた場合に警告するアドバイザーを作成しました。
MongoDBのシャーディングされていないデータベースおよびコレクションアドバイザー
シャーディングされていないデータベースとコレクションは、MongoDBシャードルーターによってデフォルトのプライマリシャードに割り当てられます。これは、データベースまたはコレクションがこのプライマリシャードのサイズに制限されていることを意味し、大量に書き込まれると、シャードの残りのディスク領域をすべて使い果たす可能性があります。これが発生すると、シャードは明らかに機能しなくなります。したがって、既存のすべてのデータベースとコレクションを監視し、構成データベースをスキャンして、シャーディングが有効になっていることを確認することが重要です。
これを防ぐために、シャーディングされていないデータベースとコレクションアドバイザを作成しました。このアドバイザーは、すべてのデータベースとコレクションをスキャンし、シャーディングされていない場合は警告します。
ClusterControlはMongoDBの保守性を改善しました
ClusterControl forMongoDBreplicaSetsとシャードクラスターにすべての改善を追加することで大きな一歩を踏み出しました。これにより、MongoDBの使いやすさが大幅に向上し、DBA、シスオペ、およびDevOpsがクラスターをさらに適切に維持できるようになります！