自己管理型コンフィギュレーションサーバーを置き換える

項目一覧

Overview

Considerations
手順

重要

次の手順は8.0コンフィギュレーションサーバーに適用されます。 MongoDB の以前のバージョンについては、対応するバージョンの MongoDB マニュアルを参照してください。

Overview

コンフィギュレーションサーバーのレプリカセットが読み取り専用になる、つまり、プライマリがない場合、シャーディングされたクラスターは、チャンクの分割や移行など、クラスターのメタデータを変更する操作をサポートできません。チャンクは分割または移行できませんが、アプリケーションはシャーディングされたクラスターにデータを書込むことができます。

いずれかのコンフィギュレーションサーバーが使用できない、または操作できない場合は、可能な限り迅速に修復または交換してください。次の手順では、コンフィギュレーションサーバーレプリカセットのノードを新しいノードに置き換えます。

チュートリアルは MongoDB 8.0に固有です。 MongoDB の以前のバージョンについては、対応するバージョンの MongoDB マニュアルを参照してください。

Considerations

次の制限は、コンフィギュレーションサーバーに使用するレプリカセット構成に適用されます。

アービタはゼロでなければなりません。
遅延ノードを含めることはできません。
インデックスを構築する必要があります（つまりどのノードも 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` の構成または DNS エントリを更新します。

レプリカセットコンフィギュレーションサーバーでは、 mongosインスタンスは--configdbまたはsharding.configDB設定でコンフィギュレーションサーバーレプリカセット名と少なくとも 1 つのレプリカセットメンバーを指定します。

そのため、 mongosインスタンスが--configdbまたはsharding.configDB設定で削除されたレプリカセットノードを指定していない場合は、それ以上のアクションは必要ありません。

ただし、 mongosインスタンスが--configdbまたはconfigDB設定で削除されたノードを指定した場合は、次のいずれかが実行されます。

次回mongosを再起動する際に設定を更新するか、
古いコンフィギュレーションサーバーを提供していたシステムを指す DNS エントリを変更して、同じホスト名が新しいコンフィギュレーションサーバーを指すようにします。

戻る

コンフィギュレーションサーバーの管理

再起動

重要