PolarDB for PostgreSQL のオンライン昇格機能を使用すると、読み取り専用ノードをプライマリノードに昇格させることができます。
適用範囲
ご利用の PolarDB for PostgreSQL クラスターは、次のいずれかのマイナーエンジンバージョンを実行している必要があります。
PostgreSQL 18、マイナーエンジンバージョン 2.0.18.0.1.0 以降
PostgreSQL 17、マイナーエンジンバージョン 2.0.17.2.1.0 以降
PostgreSQL 16、マイナーエンジンバージョン 2.0.16.3.1.1 以降
PostgreSQL 15、マイナーエンジンバージョン 2.0.15.7.1.1 以降
PostgreSQL 14、マイナーエンジンバージョン 2.0.14.5.1.0 以降
PostgreSQL 11、マイナーエンジンバージョン 2.0.11.2.1.0 以降
PolarDB コンソールで、または SHOW polardb_version; 文を実行することで、マイナーエンジンバージョンを表示できます。マイナーエンジンバージョンが要件を満たしていない場合は、マイナーエンジンバージョンをアップグレードできます。
背景情報
PolarDB for PostgreSQL は、共有ストレージをベースとした、1 つの書き込みノードと複数の読み取りノードのアーキテクチャを使用しています。これは、以下の点で従来のデータベースのプライマリ/セカンダリ アーキテクチャとは異なります。
スタンバイノード:スタンバイノードは、従来のデータベースにおけるセカンダリノードです。独立したストレージを持ち、先行書き込みログ (WAL) を完全に転送することでプライマリノードとデータを同期します。
読み取り専用ノード:レプリカノードは、PolarDB for PostgreSQL における読み取り専用のセカンダリノードです。プライマリノードとストレージを共有し、WAL メタデータを転送することでデータを同期します。
従来のデータベースは、再起動を必要とせずにスタンバイノードをプライマリノードに昇格させることをサポートしています。昇格したノードは、その後も読み取りおよび書き込みリクエストを処理し続けることができます。これにより、高可用性 (HA) が確保され、目標復旧時間 (RTO) が短縮されます。
PolarDB for PostgreSQL も、読み取り専用のセカンダリノードをプライマリノードに昇格させる機能を必要とします。レプリカノードは従来のデータベースのスタンバイノードとは異なるため、PolarDB for PostgreSQL は、1 つのライターと複数のリーダーのアーキテクチャ向けにオンライン昇格メカニズムを提供します。
使用方法
pg_ctl ツールを使用して、レプリカノードを昇格させることができます。
pg_ctl promote -D [datadir]仕組み
オンライン昇格機能は、トリガーメカニズムに基づいています。
トリガーメカニズム
PolarDB for PostgreSQL は、従来のデータベースと同じ方法でセカンダリノードを昇格させます。この機能は、次のいずれかの方法でトリガーされます。
pg_ctl ユーティリティを使用して promote コマンドを実行します。pg_ctl ユーティリティは postmaster プロセスにシグナルを送信し、postmaster プロセスは他のプロセスに必要な操作を実行して昇格を完了するように通知します。
recovery.conf ファイルで トリガーファイルのパスを定義します。この トリガーファイルが生成されると、他のコンポーネントがトリガーされます。
説明PolarDB for PostgreSQL でレプリカノードを昇格させる場合、従来のデータベースでスタンバイノードを昇格させる場合と比較して、いくつかの考慮事項があります。
レプリカノードがプライマリノードに昇格した後、共有ストレージを読み書きモードで再マウントする必要があります。
レプリカノードは、重要な制御情報をメモリ内に保持します。プライマリノードでは、この情報は共有ストレージに永続化されます。昇格中、この情報も共有ストレージに永続化する必要があります。
オンラインプロモーションプロセスでは、共有ストレージに書き込むことができるデータを特定する必要があります。
レプリカノードが WAL ログを再生する場合、そのバッファーエビクションメソッドとダーティページフラッシュの特性はプライマリノードのものとは異なります。オンライン昇格プロセスは、これらの違いを処理する必要があります。
レプリカノードの OnlinePromote プロセス中に各子プロセスを処理するためのプロシージャ。
Postmaster プロセス
postmaster プロセスは、トリガーファイルを検出するか、オンライン昇格コマンドを受信した後に、オンライン昇格プロセスを開始します。
現在のすべてのバックエンドプロセスに SIGTERM 信号を送信します。
説明読み取り専用ノードは、オンライン昇格プロセス中も読み取り専用サービスを提供し続けることができますが、データが最新ではない可能性があります。スイッチオーバー中に新しいプライマリノードから古いデータを読み取るのを防ぐために、すべてのバックエンドセッションを切断する必要があります。Startup プロセスが終了すると、読み取りおよび書き込みサービスが利用可能になります。
共有ストレージを読み取り/書き込みモードで再マウントします。
説明このステップには、基盤となるストレージからのサポートが必要です。
Startup プロセスに SIGUSR2 信号を送信して、ログのリプレイを終了し、オンライン昇格操作を処理します。
Polar Worker 補助プロセスに `SIGUSR2` シグナルを送信して、一部の LogIndex データの解析を停止します。このデータは、通常運用中のレプリカノードにのみ役立ちます。
LogIndex バックグラウンドワーカー (BGW) プロセスに SIGUSR2 信号を送信して、オンライン昇格操作を処理します。
次の図にこのプロセスを示します。

Startup プロセス
Startup プロセスは、古いプライマリノードによって生成されたすべての WAL ログをリプレイし、対応する LogIndex データを生成します。
古いプライマリノードからの最後のチェックポイントがレプリカノードでも完了したことを確認します。これにより、レプリカノードでローカルに書き込む必要があるそのチェックポイントのデータがディスクにフラッシュされることが保証されます。
LogIndex BGW プロセスが [POLAR_BG_WAITING_RESET] 状態に入るまで待機します。
レプリカノードから `clog` などのローカルデータを共有ストレージにコピーします。
WAL Meta Queue メモリ空間をリセットし、共有ストレージからスロット情報を再読み込みします。次に、LogIndex BGW プロセスのリプレイオフセットを、現在のオフセットと一貫性オフセットの最小値にリセットします。この新しいオフセットは、LogIndex BGW プロセスによる次のリプレイの開始点となります。
ノードロールがプライマリに設定され、LogIndex BGW プロセスの状態が [POLAR_BG_ONLINE_PROMOTE] に設定されます。この時点で、クラスターは読み取りおよび書き込みリクエストを処理できるようになります。
次の図にこのプロセスを示します。

LogIndex BGW の処理プロシージャ。
LogIndex BGW プロセスには独自の状態機械があり、そのライフサイクル全体を通じてこの状態機械に従って実行されます。次の表に、各状態の操作を示します。
パラメーター
説明
POLAR_BG_WAITING_RESET
LogIndex BGW プロセスの状態がリセットされます。状態機械が変更されたことを他のプロセスに通知します。
POLAR_BG_ONLINE_PROMOTE
LogIndex データを読み取り、リプレイタスクを整理・配布し、並列リプレイプロセスグループを使用して WAL ログをリプレイします。この状態のプロセスは、別の状態に切り替える前にすべての LogIndex データをリプレイする必要があります。最後に、バックグラウンドリプレイプロセスのリプレイオフセットを進めます。
POLAR_BG_REDO_NOT_START
リプレイタスクが終了したことを示します。
POLAR_BG_RO_BUF_REPLAYING
レプリカノードが正常に実行されている場合、プロセスはこの状態になります。LogIndex データを読み取り、一定量の WAL ログを順番に再生します。各ラウンドの再生後、バックグラウンド再生プロセスの再生オフセットを進めます。
POLAR_BG_PARALLEL_REPLAYING
LogIndex BGW プロセスは、一定量の LogIndex データを読み取り、リプレイタスクを整理・配布し、並列リプレイプロセスグループを使用して WAL ログをリプレイします。各リプレイラウンドの後、バックグラウンドリプレイプロセスのリプレイオフセットを進めます。
次の図にこのプロセスを示します。

LogIndex BGW プロセスが postmaster プロセスから SIGUSR2 信号を受信した後、次のようにオンライン昇格操作を実行します。
すべての LogIndex データをディスクにフラッシュし、状態を [POLAR_BG_WAITING_RESET] に切り替えます。
起動プロセスの状態が [POLAR_BG_ONLINE_PROMOTE] に切り替わるまで待機します。
レプリカノードがオンライン昇格操作を実行する前に、バックグラウンド再生プロセスはバッファープール内のページのみを再生します。
レプリカノードのオンライン昇格プロセス中に、前のプライマリノードの一部のページがメモリからディスクにフラッシュされていない可能性があります。したがって、バックグラウンド再生プロセスはすべての WAL ログを順番に再生します。再生後、`MarkBufferDirty` を呼び出してページをダーティページとしてマークし、フラッシュされるのを待ちます。
リプレイが完了すると、バックグラウンドリプレイプロセスのリプレイオフセットを進め、状態を [POLAR_BG_REDO_NOT_START] に切り替えます。
ダーティページのフラッシュ制御
各ダーティページには Oldest LSN があります。この LSN は FlushList で順序付けられ、一貫性オフセットを決定するために使用されます。
レプリカノードが昇格した後、再生と新しいページの書き込みの両方が同時に発生します。プライマリノードでは、現在の WAL 挿入オフセットがバッファーの Oldest LSN として直接設定されます。これを新しく昇格したノードで行うと、より小さい LSN を持つバッファーがディスクにフラッシュされる前に、新しい一貫性オフセットが設定される可能性があります。
したがって、レプリカノードのオンライン昇格中には、次の 2 つの問題に対処する必要があります。
古いプライマリノードから WAL ログを再生するときのダーティページの Oldest LSN の設定。
新しいプライマリノードによって生成されたダーティページの Oldest LSN の設定。
説明レプリカノードのオンライン昇格中、PolarDB for PostgreSQL は、両方の場合のダーティページの Oldest LSN を、LogIndex BGW プロセスによって進められた再生オフセットに設定します。一貫性オフセットは、同じ Oldest LSN でマークされたすべてのバッファーがディスクにフラッシュされた後にのみ進められます。