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