本記事で扱う題目は以下の通りです。

• 同期と非同期
• コンフリクト
• 統計情報ビュー
• フェイルオーバー

記事内の各リンクについて、特記のないものはすべて PostgreSQL16.4 文書（弊社ドメイン）の該当項目へのリンクとなっております。

同期と非同期

同期/非同期の概要

PostgreSQL のストリーミングレプリケーションには、同期と非同期、2通りのモードがあります。
同期と非同期の違いを簡単に言えば、スタンバイで WAL がどのような状態になったらクライアントにコミット完了を通知するかです。
以下にそれぞれの特徴を示します。

非同期モードの場合、スタンバイサーバへの複製を待たずにコミット完了するため、プライマリサーバの書き込み性能にほとんど影響を与えないことが特徴です。
しかしながら、プライマリサーバがクラッシュした場合、コミットされた一部のトランザクションがスタンバイサーバに複製されずデータ損失を引き起こす可能性があります。
データ冗長性の実現という観点では、これは大きなリスクとなることに留意してください。

対して同期モードでは、トランザクションのコミットで提供される永続性の保証範囲が拡大されます。
これにより、プライマリサーバのクラッシュ時にも、スタンバイサーバにおいては指定した同期レベルにおいて、データ損失リスクを大きく低減できることが強みとなります。
しかし、コミット完了までに適宜スタンバイでの処理を待つことになるため、プライマリのレスポンスは非同期に比べ遅くなります。

同期と非同期のそれぞれ動作の違いを以下の図に示します。

なお、PostgreSQL のストリーミングレプリケーションは、デフォルト設定では非同期となっています。

同期と非同期の設定パラメータ

ストリーミングレプリケーションが同期/非同期のどちらのモードで動作するかについては、
主に以下のパラメータによって制御されます。

• synchronous_commit

コミット完了の通知までに、完了しなければならない WAL 処理の段階を指定する

• synchronous_standby_names

同期対象として扱うスタンバイサーバを指定する

これらのパラメータはプライマリ側の postgresql.conf で設定します。
ストリーミングレプリケーションがデフォルトで非同期なのは、それぞれのパラメータのデフォルト値が「#synchronous_commit = on」「#synchronous_standby_names = ”（空文字）」であるためです。（詳細は synchronous_standby_names の項）

同期モードを指定する場合は、「どのスタンバイを同期対象として扱うか」を synchronous_standby_names で指定し、同期対象スタンバイに対して「どの段階まで WAL 処理の完了を待つか」を synchronous_commit で制御します。

ストリーミングレプリケーションが既に設定されている場合であれば、同期レプリケーションの設定には必要な追加設定は「synchronous_standby_namesを空でない値に設定すること」だけです。
synchronous_commit で同期レベルを off 以外に設定することも必要ですが、前述の通りこれはデフォルト値で on ですので、通常は変更する必要はありません。

詳細については、同期/非同期の基本設定に関するマニュアルをご確認ください。

synchronous_commit

synchronous_commit は、トランザクションのコミットを完了とみなすタイミングを制御するパラメータです。
具体的には、プライマリで行われた更新系トランザクションのコミットがクライアントに「成功」の報告を返す前に、スタンバイ側でどれだけの WAL 処理を完了する必要があるかを決めることで、永続性の保証度合が決まります。

代表的な設定値は以下の通りです。

一般的に、プライマリ障害時におけるコミット済トランザクションの更新欠損を極力回避したい場合は on が選択され、レスポンス性能とのバランスを取りたい場合は remote_write が選択されることが多いです。
remote_apply は、スタンバイ側で WAL が適用（replay）されるまで、プライマリでのコミット通知を待つ設定です。
これにより、スタンバイ側での参照クエリは、プライマリの最新データと整合性を保つことができますが、コミット完了までのレイテンシは on や remote_write と比べて大きくなる点には注意してください。
なお、local や off を指定した場合、synchronous_standby_names を設定していても実質的には非同期動作となります。

それぞれのパラメータにおける動作の違いを以下の図を示します。

また、synchronous_commit はいつでも変更可能であるため、SET を用いることで同一サーバ内でもトランザクションごとに同期レベルを使い分けることができます。
例えば、デフォルトが同期コミットの場合でも、特定のトランザクションのみを非同期でコミットしたい場合には、トランザクション内で「SET LOCAL synchronous_commit TO OFF;」を実行することで、そのトランザクションに限り非同期でレプリケーションされます。

パラメータの詳細はマニュアルをご覧ください。

synchronous_standby_names

synchronous_standby_names は、同期レプリケーションの対象とするスタンバイサーバ名を指定するパラメータです。
デフォルトの設定値は空文字「’ ‘」となっており、同期対象を指定しない設定になっています。
このように同期対象を指定しなければ、synchronous_commit が off 以外の有効な値であっても、実質的な動作は非同期の挙動となります。

同期対象となるスタンバイサーバを指定する場合は、以下のように設定します。

synchronous_standby_names = 'standby1'

この場合、application_name が standby1 であるスタンバイが同期対象となります。
application_name には、スタンバイ側の postgresql.conf で設定される primary_conninfo において、「application_name = standby1」のように指定された値（サーバ名）が使われます。
この設定は、指定するサーバがスタンバイとして起動している場合（standby.signal が存在する場合）に有効です。

二つ以上の同期スタンバイサーバ名を指定することで、より高いレベルでの高可用性とデータ損失に対する保護が期待できます。
例えば、複数のスタンバイが存在する場合、次のように指定することが可能です。

synchronous_standby_names = 'ANY 1 (standby1, standby2)'

ここで指定した ANY 1 は「standby1 と standby2 のいずれか 1 台が応答すれば同期条件を満たす」という意味になります。
これにより、いずれか一方のスタンバイに障害が発生した場合でも、書き込みが停止する事態を回避できます。

また、ANY 1 ではなく FIRST 1 を指定した場合は、スタンバイ名の記述順がそのまま優先順位となり、リストの先頭にあるスタンバイから順に同期対象として選択されます。

synchronous_standby_names = 'FIRST 1 (standby1, standby2)'

FIRST 1 の場合は、優先スタンバイが応答しない場合でも、wal_sender_timeout により接続は切断され、次に優先度の高いスタンバイが同期対象として選択されます。
そのため FIRST 1 は、「特定のスタンバイを優先しつつ、障害時には自動的に次候補へ切り替えたい」場合に有効な指定方法です。

ANY 1 と FIRST 1の挙動の違いは、以下の図のようになります。

なお、synchronous_standby_names を単にスタンバイ名をカンマ区切りで列記した場合は、暗黙的に FIRST 1 と同じ振る舞いになります。

synchronous_standby_names = 'standby1, standby2'

また、ANY 2 や FIRST 2 のように台数を 1 以上で指定した場合は、指定した台数のスタンバイに対して、synchronous_commit で指定された段階まで WAL の処理が完了するのを待ってから、クライアントにコミット完了が通知されます。

パラメータの詳細はマニュアルをご覧ください。

同期レプリケーション設定時の注意点

ここまでの説明の通り、同期レプリケーションは同期対象スタンバイからの応答（進捗通知）を必ず待ってから commit を完了するという仕組みになっています。
ですので、指定した同期スタンバイが応答しない場合は commit が完了せず、プライマリでの書き込み処理ができなくなります。

こうした状況を回避するため、同期対象のスタンバイ台数、ネットワーク遅延、スタンバイ側の性能などを考慮し、安定した稼働が実現できる範囲で設計する必要があります。
高可用性を目的とする場合でも、環境での実現性を踏まえたうえで、必ずしも常に同期レプリケーションが最適とは限らない点には注意してください。

コンフリクト

コンフリクトの概要

コンフリクトは直訳では「衝突」を意味し、PostgreSQL においては主にストリーミングレプリケーション環境において、スタンバイサーバ上で発生する、プライマリ側の更新処理とスタンバイ側で実行される参照クエリとの競合を指します。
PostgreSQL の日本語マニュアルでは、このような競合が起こる状況を「コンフリクト」と表現し、またそうした事象が発生することを「コンフリクトする」と表現しています。
コンフリクトが発生すると、解消のためにスタンバイ上で実行中の問い合わせがキャンセルされたり、セッションが終了されたりする場合がありますので、常に発生する可能性と解消方法を想定して運用することが必要となります。

以下の解説と併せて、マニュアルの該当項目「問い合わせコンフリクトの処理」もご覧ください。

コンフリクトが発生する代表的なケース

代表的なコンフリクトの例として、以下のようなケースがあります。

• スタンバイで長時間実行されている参照クエリが存在する
• プライマリで VACUUM や DELETE が実行され、不要となった行を削除しようとする
• スタンバイ側では、まだ参照中のためその行を削除できない

このようなコンフリクトが起きると、スタンバイでは WAL 適用が一時的に妨げられ、
一定時間待機した後、WAL 適用を優先するため、参照クエリがキャンセルされます。

また、コンフリクトは特にホットスタンバイの設定が「hot_standby = on（デフォルト）」と有効になっている環境で問題となります。

コンフリクト発生時のエラーメッセージ

コンフリクトが発生すると、スタンバイ側では以下のようなエラーが出力されます。

ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.

このエラーは異常動作ではなく、スタンバイでの参照とリカバリ処理の整合性を保つための正常な挙動です。

コンフリクトへの対処方法

コンフリクトへの対処方法としては、主に以下の選択肢があります。

• 「スタンバイで実行するクエリを短時間で終わるものにする」

スタンバイで実行される参照クエリの実行時間が短ければ、プライマリ側で生成された WAL を適用する際に競合が発生する可能性は低くなります。
特にスタンバイを参照用途で利用する場合は、長時間トランザクションや大規模な集計処理を避ける設計とすることで、コンフリクトによるクエリキャンセルの発生頻度を抑えることができます。

• 「パラメータでスタンバイ側の挙動を調整する」

代表的なパラメータとして、max_standby_streaming_delay や hot_standby_feedback が挙げられます。
これらパラメータを調整することで、コンフリクト発生時のスタンバイの振る舞いを制御できます。

例えば、スタンバイでの参照を優先したい場合は待機時間を長く設定したり、スタンバイ側の参照情報をプライマリに通知することで、クエリキャンセルの発生を抑制することが可能です。

なお重要な注意点ですが、これらのパラメータ調整によってコンフリクトは抑制できても、完全に防ぐことはできません。
状況によっては、スタンバイ側のクエリが ERROR によりキャンセルされるだけでなく、FATAL エラーとして接続自体が切断される場合もあります。

• 「コンフリクトによる影響をあらかじめ想定した運用を検討する」

前述のように、コンフリクトを完全に防ぐことはできないため、スタンバイを参照用途として利用する場合は、コンフリクトでクエリがキャンセルされる可能性を前提とし、エラー発生時にはクエリを再実行できる運用設計も有効です。
特にレポート生成やバッチ処理など、即時性が必須でない参照処理では、スタンバイ上のクエリのキャンセル回避を過度に追求せず、プライマリでの VACUUM が適切に進むことや、更新のスタンバイ反映を速やかに行うことを重視する運用も、現実的な選択肢です。

以下では、これら対処方法のうち、スタンバイ側の挙動を調整するためのパラメータを紹介します。

max_standby_streaming_delay

max_standby_streaming_delay：適用されようとしている WAL エントリと競合するスタンバイクエリをキャンセルするまで待機する時間を決定

スタンバイが WAL の適用（リカバリ、replay）をどれだけ遅らせて、競合している参照クエリの終了を待つかを指定するパラメータです。
言い換えるならば、「スタンバイ上の参照クエリがキャンセルされにくいこと」と、「プライマリでの更新をスタンバイに速やかに反映させること」のどちらを優先とするかを決める設定です。

本パラメータの値を大きくすると、スタンバイ側の参照クエリはキャンセルされにくくなります。
ただし、スタンバイでの WAL の適用（リカバリ処理）が遅れるため、プライマリからスタンバイへの反映に時間がかかる場合があります。
一方、値を小さく設定すると遅延（プライマリとのデータ状況の相違）は抑えられるものの、コンフリクト発生時にクエリが早期にキャンセルされやすくなります。

hot_standby_feedback

hot_standby_feedback：ホットスタンバイがスタンバイサーバ上で現在処理を行っている問い合わせについて、プライマリまたは上位サーバにフィードバックを送るか否かを指定

hot_standby_feedback を有効にすると、スタンバイが参照中の行バージョン情報をプライマリに通知することで、コンフリクトの発生を抑制します。
ただしこれに伴い、プライマリ側では VACUUM による不要な行バージョンの回収が遅れる場合があり、不要な行バージョンが残りやすくなることで、テーブルやインデックスの肥大化につながる可能性があります。

ですので、これらの設定は「スタンバイ上の参照クエリがキャンセルされにくいこと」と、「プライマリ側で VACUUM が適切に進み、テーブルの肥大化を抑えること」とのトレードオフとなります。

統計情報ビュー

レプリケーション状態の確認

ストリーミングレプリケーションの状態は、PostgreSQL が提供する統計情報ビューを用いて確認できます。
ここでは、運用時に特に重要となるビューを紹介します。

レプリケーションは高可用性や災害対策を目的とする場合がほとんどですので、運用開始以降もこれらのビューを継続的に監視することで、レプリケーションが異常なく動作していることを確認しながら運用することが、レプリケーションの目的を実現するためには必須です。
そういった意味では、単に「切れていないか」だけでなく、遅延が拡大していないか、同期設定が想定通りかといった観点で、定期的に監視することが重要です。

pg_stat_replication（プライマリ側）

pg_stat_replication は、プライマリから見たスタンバイの接続状態を確認するためのビューです。
本稿では本ビューのうち、特に有用な列を抜粋いたします。
ビューの全ての列や抜粋した列の詳細を確認する場合は、マニュアル該当項を参照してください。

pg_stat_replication ビューの参照は、任意のデータベースにpsqlなどで接続し、以下のような SELECT 文を実行します。

SELECT pid, application_name, state, sync_state, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

本ビューでは、まずは以下の項目を確認するとよいでしょう。

これらの項目を監視することで、ストリーミングレプリケーションの状況が正常か確認することができ、なんらかレプリケーションに異常が見られる場合は、
原因を特定するために有用な情報となることも期待できます。

例えば、state が streaming 以外の場合はレプリケーションが正常に行われていない可能性があり、WAL の送信や接続に何らかの問題が発生していることが考えられます。
この場合、スタンバイ側の pg_stat_wal_receiver ビューや PostgreSQL のログと突き合わせて確認することで、原因の切り分けを行うことができます。
他には、*_lag の値が継続的に増加している場合は、性能やネットワークに問題がある可能性があるというふうに見込みをつけるのに役立ちます。
（バックアップ・VACUUM時などの一時的な増加は問題ないと言えます）

• 補足：sync_state の quorum について

pg_stat_replication の sync_state 列に quorum と表示される場合、そのスタンバイが「クォーラム方式での同期対象の候補」に含まれている状態を表します。

PostgreSQL のストリーミングレプリケーションにおいては、このクォーラム方式は「synchronous_standby_names に ANY n と指定した際の挙動」と捉えてください。
前述の通り、ANY n を指定した場合、指定した台数（N 台）以上のスタンバイからの進捗通知を待ってから、プライマリはトランザクションの COMMIT を完了します。

このとき、「sync_state = quorum」と表示されたスタンバイは、 「（必要数の応答）n 台を満たすための候補となる集合の一部」 であることを示します。
つまり、quorum は明示的に指定された同期対象ではなく、ANY n 指定時に同期対象となり得るスタンバイ候補の一つであることを示す状態です。

pg_stat_wal_receiver（スタンバイ側）

pg_stat_wal_receiver は、スタンバイ側から見た WAL 受信状態を確認するためのビューです。
このビューは、主にスタンバイ側でレプリケーションが停止していないかを確認する際に有用です。

前項と同じく、本稿では本ビューのうち、特に有用な列を抜粋いたします。
ビューの全ての列や抜粋した列の詳細を確認する場合は、マニュアル該当項を参照してください。

pg_stat_wal_receiver ビューの参照は、任意のデータベースにpsqlなどで接続し、以下のような SELECT 文を実行します。

SELECT status, receive_start_lsn, received_lsn
FROM pg_stat_wal_receiver;

本ビューでは、まずは以下の項目を確認するとよいでしょう。

これらの項目を確認することで、スタンバイ側がプライマリから WAL を正しく受信できているかを把握することができます。
特に、status が streaming であり、received_lsn が継続的に進んでいる場合は、WAL の受信に関しては問題が発生していないと判断できます。

一方で、status が streaming であっても received_lsn が長時間変化しない場合は、プライマリ側での WAL 生成が少ない、あるいはネットワークや性能面での問題が発生している可能性が考えられます。
このような場合は、プライマリ側の pg_stat_replication ビューや PostgreSQL のログと突き合わせて確認することで、より詳細な原因の切り分けを行うことができます。

• 補足：WAL の LSN の概説

LSN（Log Sequence Number）とは、平たく言えば WAL の通し番号のようなもので、前述のパラメータにおいては「WAL のどこまで処理が進んでいるかを表す番号」を意味します。

プライマリとスタンバイの関係で考えると、プライマリでは「WAL を生成し、LSN が増えていく」のに対し、スタンバイでは「WAL を受信・適用し、プライマリの LSN を追いかける」という流れになります。

そのため、両者の LSN の差が小さいほど、スタンバイは新しい状態を保っていると言えます。
前述のビューを監視するにあたっては、細かな数値の意味を正確に理解しなくとも、まずは「値が進んでいるか」「止まっていないか」を見るだけでも、レプリケーションの状態把握には役立ちます。

フェイルオーバー

PostgreSQL本体でできること・できないこと

ストリーミングレプリケーションは高可用性構成の基盤となる技術ですが、PostgreSQL 本体には以下の機能は含まれていません。

• 障害検知
• 自動フェイルオーバー
• スプリットブレイン防止

そのため、フェイルオーバーの設計と運用は、外部ツールを利用したり、独自にスクリプトを組むなどの対応が必要となります。
本記事では、フェイルオーバーに関わる概要を説明します。

外部ツール利用やスクリプト構築についての詳細は、続編記事にて紹介予定のため、ここでは割愛いたします。

手動フェイルオーバーの基本

前回の記事でも紹介した通り、スタンバイは pg_ctl promote などの手段でプライマリへ昇格できます。

pg_ctl promote -D データディレクトリのパス

昇格後は、該当スタンバイは新しいプライマリとして更新を受け付けるようになります。

フェイルオーバー時の注意点

フェイルオーバー時に特に注意すべき点は以下の通りです。

• 旧プライマリが完全に停止していることを確認する
• 同時に複数のプライマリが存在しないようにする
• アプリケーションの接続先を確実に切り替える

これらが守られない場合、フェイルオーバー処理自体は正しく完了しても、スプリットブレイン（データ不整合）が発生する危険性があります。
※スプリットブレイン：複数のノードが同時にプライマリとして動作し、互いに異なる更新を受け付けてしまう状態

なお、同期レプリケーション構成であってもすべてのスタンバイが、常にプライマリの最新データと整合した状態になるとは限りません。
synchronous_standby_names の設定（ANY / FIRST）やスタンバイの接続状態によっては、同期条件を満たしていないスタンバイが存在する可能性があります。
そのため、フェイルオーバー時には「どのスタンバイが実際に同期対象であったか」、およびそのスタンバイが「昇格対象が最新の WAL を反映しているか」を必ず確認するようにしてください。

障害検知

障害検知として一般的な方法としては、定期的な ping による疎通確認や、PostgreSQL の待ち受けポートへの接続確認、もしくは pg_isready を用いたプロセスの死活監視などが考えられます。

例えば、そもそもサーバ自体に到達できない場合は OS やネットワーク障害が疑われます。
もしくはポートには接続できても pg_isready が失敗する場合は、PostgreSQL のプロセス停止や応答不能が疑われるといったように、障害を切り分けることができます。

このように、複数の観点から段階的に監視を行うことで、単純な通信断とデータベース障害とを区別しやすくなり、フェイルオーバーの判断を誤るリスクを低減できます。

自動フェイルオーバーを行う場合

自動フェイルオーバーを実現したい場合は、以下のような外部ツールとの組み合わせが一般的です。

• Pacemaker + Corosync
• pgpool-II

これらに関しての導入・操作手順は今回割愛し、次回以降の続編でご紹介する予定です。

自動フェイルオーバーを導入する場合、いずれもストリーミングレプリケーション単体の挙動を理解していることが前提となります。
まずは手動でのフェイルオーバー手順を確実に把握し、その後に自動化を検討するのが安全です。

最後に

本記事では、ストリーミングレプリケーションにおける同期設定、コンフリクト、監視、フェイルオーバーといった運用面で重要となるポイントを紹介しました。
ストリーミングレプリケーションは強力な機能ですが、その特性を正しく理解し、用途に応じた設計・運用を行うことが不可欠です。

次回以降では、pgpool-II や Pacemaker + Corosync を利用した自動フェイルオーバーの構築についての情報をお伝えする予定です。

記事内の各リンクについて、特記のないものはすべてPostgreSQL16.0文書の該当項目へのリンクとなっております。

ストリーミングレプリケーションの概要

ストリーミングレプリケーションとは

ストリーミングレプリケーションとは、PostgreSQL 9.0以降で利用できる本体組み込みのレプリケーション機能です。

本機能はWAL（Write Ahead Logging）をベースに実現しています。
具体的には、プライマリが送信したWALをスタンバイ側が受信し、スタンバイ側でそのWALをリプレイすることによりプライマリと同じ状態を保つ（リカバリし続ける）、という仕組みになっています。

PostgreSQL16.0文書 パートIII.サーバの管理 27.2.5 ストリーミングレプリケーション

プライマリとスタンバイ

プライマリやスタンバイといったサーバに対する呼び方を整理します。
ストリーミングレプリケーションを構成するサーバは、以下のふたつの役割に分けられます。

これらの関係は柔軟であり、プライマリから複数のスタンバイを並列で繋ぐ構成や、スタンバイをさらに別のスタンバイに接続する構成などを組み合わせることも可能です。
本記事では前者をマルチスタンバイ構成、後者をカスケード構成と呼ぶことにし、以下の図に表します。

ストリーミングレプリケーション導入の背景

PostgreSQL 9.0でストリーミングレプリケーションが実装されるまで、PostgreSQLでのレプリケーションには外部ツールを用いてきました。
この外部ツールの多くは「プライマリに実行されたものと同様のSQLをスタンバイに転送し実行する」ことでレプリケーションを実現しているものでした。
当時のPostgreSQLコア開発コミュニティでは用途に合わせて様々なレプリケーションツールが開発されていましたが、それらのプロダクトもいつまで使えるかの保証はなく、デファクトスタンダードとなるツールが必要とされる状況にありました。
こうした背景から、ストリーミングレプリケーションはPostgreSQLにおけるレプリケーションのデファクトスタンダードを目指して開発されました。

前述のようにストリーミングレプリケーションはWALベースの仕組みであり、その点においてそれまでのSQLベースの外部ツールとは異なります。
SQLベースでは、複雑なクエリの処理によりレプリケーションの遅延が発生したり、SQL文が意図しない結果を引き起こしデータ整合性のリスクが生じる場合があります。
こうした点において、WALベースのストリーミングレプリケーションでは、SQLベースのレプリケーションと比べ一般的に下記のようなメリットがあります。

ただし、ストリーミングレプリケーションでは物理レベルでのデータ転送が行われるため、ストレージやネットワーク帯域幅の消費が増加する可能性があります。
プライマリ・スタンバイ間のネットワーク帯域が不足している場合だと、データ転送量によっては遅延が発生することを考慮した方がよいでしょう。

それでも、データの整合性を重視する場面では、ストリーミングレプリケーションは優れた選択肢といえます。

ストリーミングレプリケーションでできること

ストリーミングレプリケーションによって、実現できる用途の代表は以下の通りです。

注意点として、障害検知機能やそれに伴う自動フェイルオーバー機能、及び負荷分散の自動化機能はPostgreSQL本体は提供していません。
これらの機能を求める場合は、外部のHAソフトウェアやクラスタリングソフトウェアなどと組み合わせるなどの対応が必要となります。
また、プライマリのデータをコピーするという点では、バックアップと役割が似ているようにも見えますが、レプリケーションの場合は誤操作なども含めレプリケーションされてしまうため、一般にバックアップにはなりません。

同期/非同期の違いについて

同期と非同期の違いは、スタンバイでWALがどのような状態になったらクライアントにコミット完了を通知するかです。
以下にそれぞれの特徴を示します。

ここでは詳細は割愛しますが、同期/非同期はプライマリのsynchronous_commitパラメータなどで設定します（デフォルトは非同期設定）。

ロジカルレプリケーションとストリーミングレプリケーションの違いについて

ストリーミングレプリケーションの特徴は、データベースクラスタ全体が物理レベルでレプリケーションされることで、プライマリとスタンバイのデータを同じ状態に保てることです。
あくまでデータベースクラスタ全体でのレプリケーションであるため、特定のテーブルや列のみを対象として限定することはできません。
また、構造が異なる環境どうしではレプリケーションできず、異なるメジャーバージョン間やOS間では利用できません。

対してロジカルレプリケーションでは、データベースやテーブル単位でWALの変更情報を論理的なレベルに変換（デコード）して転送します。
こちらは論理的な変更を行うため、異なるメジャーバージョン間やOS間でもレプリケーション可能です。
また、特定のテーブルや列のみを対象にしたレプリケーションも可能となっております。

これらの特徴を踏まえ、用途によってどちらのレプリケーションを利用するかを選ぶことで、より効率的なデータベースの運用ができるでしょう。

ロジカルレプリケーションの詳細については、以下の記事をご覧ください。

SRA OSS Tech Blog： ロジカルレプリケーションの紹介（１）

ストリーミングレプリケーションの構築

実際にストリーミングレプリケーションが動作する環境を構築していきます。
ここではプライマリに対してスタンバイは一台、非同期モードでストリーミングレプリケーションを構成します。
今回ご紹介する検証環境は以下の通りです。

※PGDG：PostgreSQL Global Development Group

①プライマリの準備

ストリーミングレプリケーション構築の準備として、プライマリ側の設定を行います。
まずはプライマリのデータベースクラスタを作成します。
以降の説明では、/usr/pgsql-16/bin/ に PATH を通してある前提で話を進めます。

$ initdb 
$ ls /var/lib/pgsql/16/data

・postgresql.confの設定（プライマリ）

下記のパラメータはどちらもデフォルト値となっています。

$ cat /var/lib/pgsql/16/data/postgresql.conf
#wal_level = replica
#max_wal_senders = 10

ここではwal_levelにreplicaを指定していますが、logicalを指定しても動作には問題ありません。
replicaに設定することで、WALアーカイビングおよびレプリケーションをサポートするために十分なデータを書き出します。
max_wal_sendersはWALを送信するプロセスの最大数を設定します。
スタンバイを複数台接続する場合は、適宜この値も調整するようにしてください。

・pg_hba.confの設定

後述するpg_basebackupの実行クライアントやスタンバイは、プライマリに対してレプリケーション接続を行います。
下記の通り、クライアント認証はデフォルトで仮想的なデータベース名replicationを指定し設定されています。

$ cat /var/lib/pgsql/16/data/pg_hba.conf
# Allow replication connections from localhost, by a user
# with the replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust

ここでは検証のために認証をtrustに設定していますが、レプリケーション接続ができるとデータの変更内容を受信できるため、現実的ではありません。
実際にはSCRAM-SHA-256を指定するなど、セキュリティを考慮した設定にしてください。

②スタンバイの準備

プライマリのデータベースクラスタをコピーし、スタンバイとして接続できるようにします。

・プライマリを起動する

$ pg_ctl start -D /var/lib/pgsql/16/data

・プライマリからベースバックアップを取得する

$ pg_basebackup -p 5432 -D /var/lib/pgsql/16/data2 -R -P
24549/24529 kB (100%), 1/1 tablespace

-Rオプションを指定すると、レプリケーションに必要な最低限の設定がpostgresql.auto.confに追加され、standby.signalが生成されます。

・postgresql.confの設定（スタンバイ）

$ vi /var/lib/pgsql/16/data2/postgresql.conf
#hot_standby = on
port = 5433

hot_standbyはリカバリ中のスタンバイが接続を受けつけ、参照ができるかを指定するパラメータです。（デフォルトでon）
portは通常変更する必要はありません。
ここでは同じホスト上でスタンバイを起動するため、プライマリのportと重複しないように変更しています。

・postgresql.auto.confの確認

編集は行わず、関連箇所のみ確認します。
前述のようにpg_basebackupで-Rオプションを指定して実行すると、接続先のプライマリの情報をもとにスタンバイの設定が自動的に追加されます。

$ cat /var/lib/pgsql/16/data2/postgresql.auto.conf
primary_conninfo = 'user=postgres passfile=' '/var/lib/pgsql/.pgpass' '(以下略)'

primary_conninfoは接続先のプライマリの接続文字列を指定するパラメータです。

・standby.signalの確認

standby.signalはスタンバイとして起動するかを指定する空のファイルです。
データベースクラスタ内にこのファイルが存在すると、サーバはスタンバイモードで起動されます。
ここではpostgresql.auto.confと同様に、pg_basebackupで-Rオプションを指定して実行したことで、自動的に生成されています。

$ ls /var/lib/pgsql/16/data2/standby.signal

③レプリケーションの動作確認

これでストリーミングレプリケーションの準備は整いました。
ここからは以下の検証を行い、レプリケーションの動作を確認します。

• プライマリに挿入したデータが、スタンバイにコピーされているか
• スタンバイでデータの挿入や削除が行えないようになっているか

それでは検証を実施していきましょう。

まずはスタンバイを起動します。

$ pg_ctl start -D /var/lib/pgsql/16/data2

次にプライマリに検証用のデータベース及びテーブルを作成し、データを挿入します。

$ createdb -p 5432 repdb
$ psql -p 5432 repdb
=# CREATE TABLE t (c int);
=# INSERT INTO t VALUES (1);
=# SELECT * FROM t;
 c 
---
 1
(1 row)

スタンバイに上記のデータが同期されているか、参照で確認します。

$ psql -p 5433 repdb
=# SELECT * FROM t;
 c 
---
 1
(1 row)

プライマリで挿入したデータがスタンバイでも参照できました。
次にスタンバイのデータに挿入を行えるかを検証してみます。

=# INSERT INTO t VALUES (2);
ERROR: cannot execute INSERT in a read-only transaction

このようにスタンバイに挿入を試みてもエラーになります。
ストリーミングレプリケーションの基本的な動作を確認することができました。

また、レプリケーションの確認として、pg_stat_replicationビューにエントリが存在するも確かめてみましょう。

$ psql -p 5432
=# SELECT * FROM pg_stat_replication;

-[ RECORD 1 ]----+------------------------------
～省略～
state      | streaming
sync_state | async

上記の state が streaming であることから、レプリケーションが正常に動作していると判断できます。
また、sync_state が async（非同期）であることも確認できます。

スタンバイ昇格と復旧手順

「プライマリが何らかの不具合で停止してしまった」
そんな時のために、ここではスタンバイをプライマリに昇格する手順をご紹介します。

①スタンバイの昇格手順

スタンバイをプライマリに昇格させる方法は複数あります。

• コマンドラインでpg_ctl promote用いる方法
• SQLでpg_promote関数を実行する方法
• promote_trigger_fileを用いる方法（PostgreSQL 15以前）

ここでは代表例として、コマンドラインでpg_ctl promoteを実行する方法を紹介します。

$ pg_ctl promote -D /var/lib/pgsql/16/data2
waiting for server to promote.... done
server promoted

これでスタンバイが新プライマリに昇格しました。
新プライマリが更新を受けつけることを確認します。

$ psql -p 5433 repdb
=# INSERT INTO t VALUES (3);
=# SELECT * FROM t;
 c 
---
 1
 3
(2 rows)

新プライマリでデータの更新ができました。
一応データベースクラスタ内のstandby.signalの有無も確認してみましょう。

$ ls /var/lib/pgsql/16/data2/standby.signal

スタンバイではなくなったことで、当該ファイルは除去されています。
なお、promote後は旧プライマリとのレプリケーションはなくなり、改めて新プライマリのシングル構成となっています。

②旧プライマリを新スタンバイにする手順と注意点

新スタンバイが昇格後、旧プライマリ側で一切WAL書き込みが発生していない状況なら、旧プライマリを新スタンバイとして組み込み可能です。
ですので、旧プライマリと旧スタンバイを単純に入れ替える場合ならば、旧プライマリを停止したうえで旧スタンバイを新プライマリに昇格するのが確実です。

しかし旧プライマリと新プライマリの間にデータのずれがある状況では、単純に旧プライマリを新スタンバイとしてレプリケーションを構築することができません。
その場合、以下の方法でスタンバイを構築する必要があります。

• 再度新プライマリから pg_basebackup で ベースバックアップを取得しなおす
• pg_rewindで旧プライマリを新プライマリと同期させる

・pg_basebackupを用いる場合

一つ目の方法のベースバックアップに関しては、前述の「ストリーミングレプリケーションの構築」で紹介したと同様の手順で実行できます。
基本的にはこちらの方法で愚直にバックアップを取り直したうえで、改めてレプリケーションを構成することが安全で確実といえます。

・pg_rewindを用いる場合

二つ目の方法のpg_rewindを使用するには以下の条件をクリアしている必要があります。

• 事前にwal_log_hintsをonに設定しておく。（デフォルトはoff）
  もしくはpg_checksums -eでデータチェックサムを有効にしておく。（-e オプションで有効化）
• full_page_writesをonにしておく。（デフォルトでon）

これらの設定は後から設定しても、その直後はpg_rewindを使用できないため、あらかじめ設定しておくことを忘れないようにしてください。
データベースクラスタが大きい場合には、pg_rewindの方がベースバックアップに比べて復旧時間が短縮できます。
これはpg_rewindの方が差分同期で済むためです。

pg_rewindとpg_basebackupのどちらの手段を選択するかは、ストリーミングレプリケーションを構成する際にあらかじめ想定しておくとよいでしょう。

最後に

本記事ではストリーミングレプリケーションの概要と、基本的な構築手順をご紹介いたしました。
次回以降では、

・同期と非同期についての詳細
・コンフリクトについて
・統計情報ビューの確認方法
・フェイルオーバーについて

など運用に関わる情報をお伝えする予定です。