ロールバックは、フェイルオーバー後にレプリカセットに再参加したときに、以前の プライマリ に対する書込み (write){ w: "majority" } 操作を元に戻します。 Atlas クラスターはMongoDBのデフォルトの書込み保証 (write concern)として を使用します。このデフォルトの では、Atlas は、書込みを過半数のノードにレプリケートした後にのみ書込みを確認します。確認済みの書込みはロールバックできないため、ロールバックによってデータが失われることはありません。
{ w: 1 }書込み保証 (write concern)を構成している場合、ロールバックはまだレプリケーションされていない書込みに影響を与える可能性があります。ロールバックが発生する前に、ロールバックされた操作を識別し、それらを再発行するかどうかを決定する方法を計画します。
レプリカセットのロールバックの仕組みについては、「 レプリカセットフェイルオーバー中のロールバック 」を参照してください。
Atlas でのロールバック動作
Atlas でロールバックが発生すると、次の条件が適用されます。
Atlas
HOST_ROLLBACKは、プロジェクトのアクティビティフィードに イベントを生成します。このイベントを確認する方法については、「 ロールバックの検出 」を参照してください。Atlas はロールバックされた操作のリストを保持しません。
書込み保証とロールバックのリスク
Atlas{ w: "majority" } クラスターはMongoDBのデフォルトの書込み保証 (write concern)として を使用します。このデフォルトの では、ロールバックによってデータが失われることはありません。ロールバックによってデータが失われるかどうかは、設定した書込み保証 (write concern)によって決まります。
{ w: "majority" }（デフォルト）_ Atlas は、レプリカセットノードの過半数が書込みを確認した後にのみ書込みを認識します。書込み (write) はプライマリが降格する前に複製されたため、ロールバックにはこれらの書込みを含めることはできません。{ w: 1 }— Atlas は、セカンダリへのレプリケーションを待たずに、プライマリのみが書込み (write) を記録した後に書込み (write) を確認します。書込み (write) が複製される前にプライマリが降格した場合、書込み (write) はロールバックされ、データを回復できなくなる可能性があります。
自己管理型配置とは異なり、Atlas は次のような定期的なメンテナンス操作中にレプリカセットの選挙もトリガーされます。
ローリング メンテナンスとパッチ アップデート
クラスター層やディスク サイズの変更など、 イベントのスケーリング
一般的なクラスター構成の変更
Atlas はダウンタイムを回避するために、これらの操作を順次実行します。ただし、各選挙では、{ w: 1 } の書込みがセカンダリに複製されない期間が生じます。 { w: 1 } を使用する場合は、ロールバック リスクの許容度を評価する際にこれらの選挙ソースを考慮してください。
ロールバックの検出
Atlas がフェイルオーバー中にロールバック条件を検出すると、 HOST_ROLLBACKイベントを生成します。このイベントは、次の方法で確認できます。
アクティビティ フィード:プロジェクトのアクティビティフィードで
HOST_ROLLBACKイベントを表示します。詳しくは、「 アクティビティ フィードを表示 」を参照してください。アラート:イベント発生時に通知を受信するように、
HOST_ROLLBACKイベントタイプでアラートを構成します。詳しくは、「 アラート設定の構成 」を参照してください。
注意
AtlasHOST_ROLLBACK は、ソースクラスターとターゲットクラスター間のデータ違いにより、ポイントインタイム復元操作中に イベントも生成します。そのコンテキストで発生した場合、このイベントを無視できます。詳細については、「 継続的なクラウドバックアップからの復元 」を参照してください。
ロールバック データの回復
ロールバックが発生した場合は、 MongoDBサポート に問い合わせて、ロールバックされたデータを回復できるかどうかを判断してください。