クラスターのメンテナンスに準備する
Cloud Managerは、クラスター内のノードの メンテナンスを実行する ときに ローリング再起動 を実行します。オートメーションは、メンテナンス期間中にクラスターの可用性を維持するために更新されるまで、クラスター内のノードを 1 つずつ更新します。
クラスターのメンテナンスを実行する前に、以下の考慮事項を確認し、必要に応じてアクションを実行して、クラスターの可用性を維持してください。
注意
オートメーションがクラスターのメンテナンスを実行する方法については、「 Cloud Manager がクラスター ノードのメンテナンスをどのように実行しますか 」を参照してください。
oplog サイズ
メンテナンスが開始される前に、クラスター内の各ノードは スタンドアロン モードで再起動されます。 ノードはoplogの書込み (write) を再生し、メンテナンスが完了した後に クラスターに戻されると、他のノードに追いつくために します。
クラスターの oplog が、メンテナンス期間中にアプリケーションが実行する可能性のあるすべての書き込みを保存するのに十分な大きさであることを確認してください。 oplog サイズを調整するには、 replication.oplogSizeMB高度な配置オプションを使用します。
優先順位
プライマリ ノードでメンテナンスが開始されると、そのプライマリ ノードへのすべてのクライアント接続が切断されます。 新しく選出されたプライマリ ノードへの接続が再確立されます。
特定のデータセンター内のノードを新しいプライマリ ノードにすることができます。 クラスターの構成を編集し、各ノードの優先順位を調整して、使用するプライマリ ノードを示します。
フォールトトレランス
メンテナンス中のノードは、クラスターへの フェイルオーバー サポートを提供しません。 3 ノードのレプリカセットの場合、1 つのノードがメンテナンスを実行しているときに追加のノードが使用できなくなると、クラスターは大多数のノードを返します。 プライマリ ノードはこのステータスを失い、セカンダリ ノードに降格します。 クラスターのノードの過半数が利用可能になるまで、新しいプライマリを選出できません。
アップタイムが必要なシステムクリティカル アプリケーションの場合は、メンテナンス期間中に追加のクラスター ノードが使用できなくなった場合に備えて、クラスターの過半数を維持するために、メンテナンスを実行する前に 3 ノードのレプリカセットを 5 つのノードのレプリカセットに変換することを検討してください。
注意
5 ノード以上のレプリカセットは回復力があり、メンテナンス期間中に過半数が失われる可能性は低くなります。
複数の障害耐性を高めるためのより簡単ではありますが、回復力のないオプションは、メンテナンスを実行する前に 3 つのノードのレプリカセットに一時的なアービタを追加することです。
一意のインデックス構築
オートメーションは、同一であるが独立したコマンドを使用して、クラスター ノードに一度に 1 つずつインデックスを構築します。 書き込みが一意なインデックス のインデックス付きフィールドのunique品質を尊重するようにするには、インデックスを構築する前にクラスター上のコレクションへのすべての書き込みを停止する必要があります。
Cloud Manager のData ExplorerまたはAutomation Config リソースを使用して、一意のインデックスをローリング方式で作成することはできません。これらのメソッドはクラスターへの書込みを停止しないためです。
ユースケースで新しい一意なインデックスを構築する必要がある場合は、次のようにします。
影響を受けるコレクションへの書き込みをすべて停止します。 詳しくは を参照してください。 MongoDB マニュアルのdb.fsyncLock()を参照してください。
MongoDB マニュアルの「レプリカセットのインデックスの構築」を参照して、一意のインデックスをローリング方式で構築します。