自己管理型シャーディングされたクラスターを異なるハードウェアに移行
チュートリアルは MongoDB 8.0に固有です。 MongoDB の以前のバージョンについては、対応するバージョンの MongoDB マニュアルを参照してください。
シャーディングされたクラスターのコンフィギュレーションサーバーはレプリカセットとして配置されます。 レプリカセット コンフィギュレーションサーバーは、 WiredTiger ストレージ エンジン を実行する必要があります。
この手順により、シャーディングされたクラスターのコンポーネントは新しいハードウェア システムに移動され、読み取りと書込みのダウンタイムは発生しません。
重要
移行の進行中は、 シャーディングされたクラスターのメタデータへの変更は行わないでください。 クラスター メタデータを 絶対的な方法で 変更する操作は 使用しない でください。 たとえば、データベースの作成や削除、コレクションの作成や削除、シャーディング コマンドは使用 しない でください。
始める前に
MongoDB 8.0 以降では、 directShardOperations ロールを使用して、メンテナンス操作を実行できます。その操作では、シャードに対してコマンドを直接実行する必要があります。
警告
directShardOperationsロールを使用して コマンドを実行すると、クラスターが正しく動作しなくなり、データが破損する可能性があります。 directShardOperationsロールは、メンテナンス目的で、または MongoDB サポートのガイダンスに必ず従う必要があります。 メンテナンス操作を実行したら、 directShardOperationsロールの使用を停止します。
バランサーを無効にする
バランサーを無効にしてチャンクの移行を停止し、プロセスが完了するまでメタデータの書込み操作を実行しません。 移行が進行中の場合、バランサーは進行中の移行を完了してから停止します。
バランサーを無効にするには、クラスターのmongosインスタンスの 1 つに接続し、次のメソッドを発行します。 [ 1 ]
sh.stopBalancer()
バランサーの状態を確認するには、 sh.getBalancerState()メソッドを発行します。
詳細については、「バランサーを無効にする 」を参照してください。
| [1] | MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません6.0.3より前のバージョンの MongoDB では、 sh.stopBalancer()は、シャーディングされたクラスターの自動分割も無効にします。 |
各コンフィギュレーションサーバーを個別に移行する
シャーディングされたクラスターのコンフィギュレーションサーバーは、レプリカセット（CSRS） としてデプロイできます。コンフィギュレーションサーバーにレプリカセットを使用すると、複数のコンフィギュレーションサーバー間での整合性を高めることができます。これは、MongoDB がコンフィギュレーションデータに対して標準レプリカセットの読み取りおよび書き込みプロトコルを利用できるためです。さらに、コンフィギュレーションサーバーにレプリカセットを使用すると、レプリカセット 1 つに最大 50 ノードを含めることができるため、シャーディングされたクラスターに 3 台を超えるコンフィギュレーションサーバーを設定することができます。コンフィギュレーションサーバーをレプリカセットとして展開するには、コンフィギュレーションサーバーによりWiredTiger ストレージ エンジンが実行されている必要があります。
次の制限は、コンフィギュレーションサーバーに使用するレプリカセット構成に適用されます。
インデックスを構築する必要があります（つまり、どのノードも
members[n].buildIndexes設定を false に設定しないでください。）
コンフィギュレーションサーバーの各ノードの場合
重要
プライマリ ノードを置き換える前に、セカンダリ ノードを置き換えます。
置換コンフィギュレーションサーバーを起動します。
--configsvr 、 --replSet 、 --bind_ipオプション、および配置に応じてその他のオプションを指定して、 mongodインスタンスを起動します。
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
mongod --configsvr --replSet <replicaSetName> --bind_ip localhost,<hostname(s)|ip address(es)>
新しいコンフィギュレーションサーバーをレプリカセットに追加します。
mongoshをコンフィギュレーションサーバー レプリカセットのプライマリに接続し、 rs.add()を使用して新しいノードを追加します。
警告
MongoDB 5.0 より前では、新しく追加されたセカンダリは、データの一貫性が確保されるまでは読み取りを処理できず、プライマリにもなれませんが、投票メンバーとしてカウントされます。MongoDB バージョン 5.0 より前のバージョンを実行中で、 votesとpriorityの設定が0より大きいセカンダリを追加すると、投票ノードの過半数がオンラインであるにもかかわらずプライマリを選出できない状況が発生する可能性があります。このような状況を回避するには、最初にpriority :0とvotes :0を使用して新しいセカンダリを追加することを検討してください。次に、 rs.status()を実行して、ノードがSECONDARY状態に移行したことを確認します。最後に、 rs.reconfig()を使用して優先順位と投票をアップデートします。
rs.add( { host: "<hostnameNew>:<portNew>", priority: 0, votes: 0 } )
最初の同期プロセスでは、コンフィギュレーションサーバーのレプリカセットの 1 つのノードから再起動せずに新しいノードにすべてのデータがコピーされます。
mongos インスタンスは、再起動せずに、コンフィギュレーションサーバー レプリカセット ノードの変更を自動的に認識します。
新しく追加されたコンフィギュレーションサーバーの投票と優先順位設定を更新します。
新しいノードが
SECONDARY状態に達していることを確認します。 レプリカセット メンバーの状態を確認するには、rs.status()を実行します。rs.status() レプリカセットを再構成して、新しいノードの投票と優先順位を更新します。
var cfg = rs.conf(); cfg.members[n].priority = 1; // Substitute the correct array index for the new member cfg.members[n].votes = 1; // Substitute the correct array index for the new member rs.reconfig(cfg) ここで、
nはmembers配列内の新しいノードの配列インデックスです。
警告
rs.reconfig()shell メソッドを使用すると、現在のプライマリを強制的に降格させることができ、選挙が行われます。プライマリが降格すると、mongodはすべてのクライアント接続を閉じます。通常、この処理時間は 10 ～ 20 秒ですが、スケジュールされたメンテナンス期間中にこれらの変更を行ってください。MongoDB のバージョンによって検証ルールが異なる可能性があるため、異なるバージョンの MongoDB のノードを含むレプリカセットの再設定は避けてください。
置き換えるノードをコンフィギュレーションサーバーのレプリカセットから削除します。
置き換えコンフィギュレーションサーバーの最初の同期が完了したら、プライマリに接続されているmongoshセッションから、 rs.remove()を使用して古いノードを削除します。
rs.remove("<hostnameOld>:<portOld>")
mongos インスタンスは、再起動せずに、コンフィギュレーションサーバー レプリカセット ノードの変更を自動的に認識します。
インスタンスを再起動するmongos
レプリカセット コンフィギュレーションサーバーでは、 mongosインスタンスは--configdbまたはsharding.configDB設定でコンフィギュレーションサーバー レプリカセット名と少なくとも 1 つのレプリカセット メンバーを指定します。 シャーディングされたクラスターのmongosインスタンスは、同じコンフィギュレーションサーバー レプリカセット名を指定する必要がありますが、レプリカセットの異なるノードを指定できます。
mongosインスタンスが--configdbまたはsharding.configDB設定で移行されたレプリカセット ノードを指定した場合は、次にmongosインスタンスを再起動するときに、コンフィギュレーションサーバーの設定を更新します。
シャードの移行
シャードを一度に 1 つずつ移行します。 各シャードについて、このセクションの適切な手順に従います。
レプリカセット シャードの移行
シャーディングされたクラスターを移行するには、各ノードを個別に移行します。 最初に非プライマリ メンバーを移行し、次に最後のプライマリメンバーを移行します。
レプリカセットに 2 つの投票ノードがある場合は、レプリカセットにアービタを追加して、移行中もセットが投票の過半数を利用できるようにします。 移行が完了した後に、アービタを削除できます。
レプリカセット シャードのノードの移行
mongodプロセスをシャットダウンします。 確実にクリーンなシャットダウンを行うには、shutdownコマンドを使用します。データディレクトリ（
dbPath）を新しいマシンに移動します。新しい場所で
mongodプロセスを再起動します。レプリカセット の現在のプライマリに接続します。
メンバーのホスト名が変更された場合は、
rs.reconfig()を使用してレプリカセット構成ドキュメントを新しいホスト名で更新します。たとえば、次のコマンド シーケンスは、
members配列内の位置2にあるインスタンスのホスト名を更新します。cfg = rs.conf() cfg.members[2].host = "pocatello.example.net:27018" rs.reconfig(cfg) 構成ドキュメントのアップデートの詳細については、「例」を参照してください。
新しい構成を確認するには、
rs.conf()を実行します。ノードが回復するまで待ちます。 メンバーの状態を確認するには、
rs.status()を発行します。
レプリカセット シャード内のプライマリの移行
レプリカセットのプライマリを移行する間、セットは新しいプライマリを選択する必要があります。 この フェイルオーバー プロセスは、選挙中にレプリカセットを読み取りを実行したり、書込みを受け入れたりすることができなくなります。このプロセスは通常すぐに完了します。 可能であれば、メンテナンスウィンドウ中に移行を計画してください。
プライマリを降格して、通常のフェイルオーバープロセスを許可します。 プライマリを降格するには、プライマリに接続して、
replSetStepDownコマンドまたはrs.stepDown()メソッドを発行します。 次の例には、rs.stepDown()メソッドが示されています。rs.stepDown() プライマリが降格し、別のノードが
PRIMARY状態になったら、 ステップダウンしたプライマリを移行するには、「 レプリカセット シャードのノードの移行 」の手順に従います。ステータスの変化を確認するには、
rs.status()の出力を確認します。
バランサーを再度有効にする
移行を完了するには、バランサーを再度有効にして、チャンクの移行を再開します。
クラスターのmongosインスタンスの 1 つに接続し、 trueをsh.startBalancer()メソッドに渡します[ 2 ]
sh.startBalancer()
バランサーの状態を確認するには、 sh.getBalancerState()メソッドを発行します。
詳細については、 「 バランサーを有効にする 」を参照してください。
| [2] | MongoDB 6.0.3以降、 自動チャンク分割は実行されません。 これはバランシング ポリシーの改善によるものです。 自動分割コマンドは引き続き存在しますが、操作は実行されません6.0.3より前のバージョンの MongoDB では、 sh.startBalancer()は、シャーディングされたクラスターの自動分割も有効にします。 |