自動フェイルオーバー¶
プライマリで予期しないエラーが発生した場合、クラスターは フェールオーバーモード になります。これは、たとえば次の場合に発生する可能性があります。
プライマリポッドにディスク障害があります
プライマリポッドが削除される
プライマリの
postgresコンテナに何らかの持続的な障害があります
フェールオーバーのシナリオでは、プライマリが正常に動作していると想定できません。
上記のようなケースの後、プライマリポッドのreadinessプローブが失敗し始めます。これは、コントローラーの調整ループで検出されます。コントローラーは、次の2つの手順でフェールオーバープロセスを開始します。
1.最初に、TargetPrimary をpending
としてマークします。この状態の変化により、プライマリポッドが強制的にシャットダウンされ、レプリカのWALレシーバーが停止します。クラスターはフェールオーバーフェーズ
(「フェールオーバー」) でマークされます。
2.すべてのWALレシーバーが停止すると、リーダー選挙が行われ、新しいプライマリが命名されます。選択されたインスタンスはプライマリへの昇格を開始し、これが完了すると、クラスターは通常のオペレーションを再開します。一方、以前のプライマリポッドは再起動し、プライマリではなくなったことを検出し、レプリカノードになります。
重要
この2フェーズの手順は、WALレシーバーを正常に停止でき、障害が発生したプライマリが再起動時にWALのストリーミングを再開しないことを保証します。これらの安全対策により、新しいプライマリとレプリカ間のタイムラインの不一致が防止されます。
障害が発生したプライマリがシャットダウンされている間：
1.最初に、タイムアウトとして.spec.switchoverDelay
秒でPostgreSQLの高速シャットダウンを試行します。このグレースフルシャットダウンは、保留中のWALをアーカイブしようとします。
2.高速シャットダウンが失敗するか、タイムアウトを超えた場合、PostgreSQLの即時シャットダウンが開始されます。
RTOとRPOへの影響¶
フェールオーバーにより、サービスが影響を受けたり、データが失われたりする可能性があります。
1.プライマリに障害が発生し始めた間、コントローラがフェイルオーバー手順を開始する前に、転送中のクエリ、WAL書き込み、チェックポイントおよび同様の操作が失敗する場合があります。
2.高速シャットダウンコマンドが発行されると、クラスターは接続を受け入れなくなるため、サービスは影響を受けますが、データは失われません。
3.高速シャットダウンが失敗した場合、即時シャットダウンはWAL書き込みを含む保留中のプロセスを停止します。データが失われる可能性があります。
4.プライマリがシャットダウンし、新しいプライマリがまだ起動していない間、クラスターはプライマリなしで動作するため、障害が発生しますが、データは失われません。
注釈
高速シャットダウンを制御するタイムアウトは、スイッチオーバーの場合と同様に`.spec.switchoverDelay` によって設定されます。高速シャットダウンの時間を長くすることは、RPOの観点からは安全ですが、通常の操作への復帰が遅れる可能性があり、RTOに悪影響を及ぼします。
警告
スイッチオーバープロセスを説明するときに インスタンスマネージャーのインプレース更新 で既に述べたように、 .spec.switchoverDelay オプションはPostgreSQLデータベースのRPOとRTOに影響します。低い値に設定すると、RPOよりもRTOが優先される場合がありますが、クラスターレベルおよび/またはバックアップレベルでデータが失われます。逆に、これを高い値に設定すると、スイッチオーバー中にアクティブなプライマリなしでクラスターを長時間放置するときに、データ損失のリスクが削除される場合があります。
