MongoDB8.0 以降では、通常の シャーディングされたクラスターのメタデータデータ に加えて、アプリケーションデータを保存するようにコンフィギュレーションコンフィギュレーションサーバーを構成できます。アプリケーションデータを保存するコンフィギュレーションコンフィギュレーションサーバーは、 コンフィギュレーションシャード または 埋め込みコンフィギュレーションコンフィギュレーションサーバーと呼ばれます。
レプリカセットをコンフィギュレーションシャード が埋め込まれたシャーディングされたクラスターに変換すると、以下の削減が可能です。
配置に必要なノードの数。
単一シャード クラスターを維持するための複雑さ。
このタスクについて
MongoDB 8.3 以降では、埋め込みコンフィギュレーションシャードを使用して、レプリカセットをシャーディングされたクラスターに直接変換できます。
前のリリースでは、まずレプリカセットを専用のコンフィギュレーションサーバーレプリカセットを使用してクラスターに変換し、次に埋め込まれたシャードがあるものに変換する必要があります。
アクセス制御
アクセス制御が有効になっている場合、transitionFromDedicatedConfigServer コマンドにはtransitionFromDedicatedConfigServer クラスター に対する 承認 アクションが必要です。
clusterManagerロールにはtransitionFromDedicatedConfigServer 認可アクションがあり、ユーザーに割り当てることができます。
始める前に
MongoDB 8.3 以降では、以前にシャーディングされたクラスターであったレプリカセットをレプリカセットに変換することはできません。
シャーディングされたクラスターをレプリカセットに変換すると、 シャード ID documentなど、以前の配置のシャーディングメタデータが保持され、再度シャーディングされたクラスターになるのがブロックされます。自己管理型変換をシャーディングされたクラスターに戻しようとすると、 MongoDB はエラーを返します。
このようなレプリカセットをシャーディングされたクラスターに変換するには、テクニカル サポート にお問い合わせください。
手順
次の例では、自己管理型レプリカセットを、レプリカセットの既存のユーザー データを含むコンフィギュレーションシャードに変換します。
レプリカセットを メンテナンスモードにします。
レプリカセットでローリング再起動を実行します。メンテナンスモードで各ノードをコンフィギュレーションサーバーとして起動します。
セカンダリ から始めて各ノード を停止します。サーバーをシャットダウンするには、
db.shutdownServer()メソッドを使用します。db.shutdownServer() メンテナンスモードでノードをコンフィギュレーションシャードとして再起動します。
mongod --config /etc/mongodb.conf --configsvr \ --replicaSetConfigShardMaintenanceMode \ --configsvrmongodインスタンスをコンフィギュレーションサーバーとして起動します。--replicaSetConfigShardMaintenanceMode- コンフィギュレーションシャード メンテナンスモードを有効にします。これにより、一部のスタートアップチェックが無効になり、サーバーを埋め込みコンフィギュレーションシャードに変換できるようになります。
ノードがレプリカセットに再び追加されるまで待ってから、次のノードを再起動します。
プライマリノードを見つけます。
新しいプライマリノードを識別するには、rs.status() メソッドを使用します。大規模なレプリカセットがある場合は、db.aggregate() メソッドを使用して検索を絞り込みます。
db.aggregate( [ { $documents: rs.status().members }, { $match: { stateStr: "PRIMARY" } }, { $project: { _id: 1, name: 1 } ] )
[ { _id: 3, name: "192.0.2.3:27017" } ]
プライマリをコンフィギュレーションシャードに変換する。
プライマリノードに接続し、埋め込みコンフィギュレーションシャードとして動作するように再構成します。
rs.conf()メソッドを使用して現在の構成をGETし、それを変数に保存します。var conf = rs.conf() configsvrフィールドを に設定します。conf.configsvr = true versionフィールドを増やします。conf.version += 1 ノードを再構成します。
rs.reconfig(conf) セカンダリ が変更を複製するまで待ちます。ノードのdocumentに対して集計パイプラインを実行することで、ステータスを確認できます。
db.aggregate( [ { $documents: rs.status().members }, { $group: { _id: null, allConfigSvr: { $min: { $eq: ["$configsvr", true] } } } } ] ) { _id: null, allConfigSvr: true } allConfigSvrにtrueが表示されている場合は、再構成がクラスター内のすべてのノードに伝達されたことを示します。
クラスターを再起動します。
ローリング アップグレードを実行して、レプリカセットをコンフィギュレーションサーバーとして再起動します。
セカンダリ から始めて各ノード を停止します。サーバーをシャットダウンするには、
db.shutdownServer()メソッドを使用します。db.shutdownServer() メンテナンスモードではなく、コンフィギュレーションサーバーとしてノードを再起動します。
mongod --config /etc/mongodb.conf --configsvr
ルーターを起動します。
mongos ルーターを起動します。
mongos --config /etc/mongodb.conf
コンフィギュレーションサーバーを埋め込みコンフィギュレーションシャードに移行する。
mongos に接続し、transitionFromDedicatedConfigServer コマンドを実行してコンフィギュレーションシャードをクラスターに追加します。
db.adminCommand( { transitionFromDedidcatedConfigServer: 1 } )
アプリケーションをルーターにポイントします。
レプリカセットではなく、mongos ルーターに接続するようにアプリケーションを更新します。