クラスターのメンテナンスに準備する

oplog サイズ

メンテナンスが開始される前に、クラスター内の各ノードは スタンドアロン モードで再起動されます。 ノードはoplogの書込み (write) を再生し、メンテナンスが完了した後に クラスターに戻されると、他のノードに追いつくために します。

クラスターの oplog が、メンテナンス期間中にアプリケーションが実行する可能性のあるすべての書き込みを保存するのに十分な大きさであることを確認してください。 oplog サイズを調整するには、 replication.oplogSizeMB高度な配置オプションを使用します。

優先順位

プライマリ ノードでメンテナンスが開始されると、そのプライマリ ノードへのすべてのクライアント接続が切断されます。 新しく選出されたプライマリ ノードへの接続が再確立されます。

特定のデータセンター内のノードを新しいプライマリ ノードにすることができます。 クラスターの構成を編集し、各ノードの優先順位を調整して、使用するプライマリ ノードを示します。

フォールトトレランス

メンテナンス中のノードは、クラスターへの フェイルオーバー サポートを提供しません。 3 ノードのレプリカセットの場合、1 つのノードがメンテナンスを実行しているときに追加のノードが使用できなくなると、クラスターは大多数のノードを返します。 プライマリ ノードはこのステータスを失い、セカンダリ ノードに降格します。 クラスターのノードの過半数が利用可能になるまで、新しいプライマリを選出できません。

アップタイムが必要なシステムクリティカル アプリケーションの場合は、メンテナンス期間中に追加のクラスター ノードが使用できなくなった場合に備えて、クラスターの過半数を維持するために、メンテナンスを実行する前に 3 ノードのレプリカセットを 5 つのノードのレプリカセットに変換することを検討してください。

複数の障害耐性を高めるためのより簡単ではありますが、回復力のないオプションは、メンテナンスを実行する前に 3 つのノードのレプリカセットに一時的なアービタを追加することです。

一意のインデックス構築

オートメーションは、同一であるが独立したコマンドを使用して、クラスター ノードに一度に 1 つずつインデックスを構築します。 書き込みが一意なインデックス のインデックス付きフィールドのunique品質を尊重するようにするには、インデックスを構築する前にクラスター上のコレクションへのすべての書き込みを停止する必要があります。

Cloud Manager のData ExplorerまたはAutomation Config リソースを使用して、一意のインデックスをローリング方式で作成することはできません。これらのメソッドはクラスターへの書込みを停止しないためです。

ユースケースで新しい一意なインデックスを構築する必要がある場合は、次のようにします。

1. 影響を受けるコレクションへの書き込みをすべて停止します。 詳しくは を参照してください。 MongoDB マニュアルのdb.fsyncLock()を参照してください。

2. MongoDB マニュアルの「レプリカセットのインデックスの構築」を参照して、一意のインデックスをローリング方式で構築します。