Automated failover

プライマリで予期しないエラーが発生した場合、クラスターは フェイルオーバーモード に入ります。これは、例次の場合に発生する可能性があります。

• プライマリポッドにディスク障害があります

• プライマリポッドが削除されます

• プライマリの postgres コンテナには、あらゆる種類の持続的な障害があります

フェイルオーバーシナリオでは、プライマリが正常に動作していると想定することはできません。

上記のようなケースの後、プライマリポッドのレディネスプローブは失敗し始めます。これは、コントローラーの調整ループで取得されます。コントローラーは、2つのステップでフェイルオーバープロセスを開始します。

1.最初に、 TargetPrimary を pending としてマークします。この状態の変更により、プライマリポッドが強制的にシャットダウンされ、レプリカ上のWALレシーバーが保証に停止します。クラスターはフェールオーバーフェーズ（「フェイルオーバー」）でマークされます。すべてのWALレシーバーが停止すると、リーダー選挙が行われ、新しいプライマリが名前付けます。選択したインスタンスはプライマリへの昇格を開始し、これが完了すると、クラスターは通常の操作を再開します。一方、以前のプライマリポッドはリスタートし、それがプライマリではなくなったことを検出し、レプリカノードになります。

保証 2フェーズプロシージャは、WALレシーバーが正常に停止できるようにし、障害が発生したプライマリが再スタート時にWALのストリーミングをリスタートしないようにします。これらのセーフガードは、新しいプライマリとレプリカの間のタイムラインの不一致を防ぎます。

障害のあるプライマリがシャットダウンされている間：

1.まず、タイムアウトとして .spec.switchoverDelay 秒でPostgreSQLの高速シャットダウンを試みます。この正常なシャットダウンは、保留中のWALをアーカイブしようとします。高速シャットダウンが失敗するか、タイムアウトが超過すると、PostgreSQLの即時シャットダウンが開始されます。

RTOおよびRPOのインパクト

フェイルオーバーにより、サービスが影響を受けたり、データが失われたりする可能性があります。

1.プライマリが失敗し始め、コントローラがフェイルオーバー手順を開始する前に、送信中のクエリ、WAL書き込み、チェックポイントなどの操作が失敗する場合があります。高速シャットダウンコマンドが発行されると、クラスターは接続を受け入れなくなるため、サービスは影響を受けますが、データは失われません。高速シャットダウンが失敗した場合、即時シャットダウンはWAL書き込みを含む保留中のプロセスをすべて停止します。データが失われる可能性があります4。プライマリがシャットダウンされ、新しいプライマリがまだ開始されていない間、クラスタはプライマリなしで動作するため、障害が発生しますが、データロスれません。

注釈

高速シャットダウンを制御するタイムアウトは、スイッチオーバーの場合と同様に、 .spec.switchoverDelay によって設定されます。高速シャットダウンの時間を長くすることは、RPOのビューからは安全ですが、通常のオペレーションへの結果を遅らせる可能性があり、RTOに悪影響を及ぼします。

警告

スイッチオーバープロセスの説明で インスタンスマネージャのインプレース更新 で既に述べたように、 .spec.switchoverDelay オプションはPostgreSQLデータベースのRPOとRTOに影響します。これを低い値に設定すると、RPOよりもRTOが優先されますが、クラスターレベルやバックアップレベルでデータロスれる可能性があります。反対に、高い値に設定すると、スイッチオーバー中により長い時間アクティブなプライマリがないクラスタを残しながら、データロスのリスクを取り除くことができます。