自己管理型シャーディングされたクラスターを異なるハードウェアに移行

項目一覧

始める前に
バランサーを無効にする
各コンフィギュレーションサーバーを個別に移行する
mongosインスタンスを再起動する
シャードの移行
バランサーを再度有効にする

チュートリアルは 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インスタンスを再起動するときに、コンフィギュレーションサーバーの設定を更新します。

詳細については、「シャーディングされたクラスターの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()