1.4レプリケーション運用

Silver でレプリケーションは「基礎知識」の対象でしたが、Gold では実際に構築し、同期方式を選び、遅延やギャップを監視する運用者の視点が求められます。可用性要件（どこまで止まってよいか）とデータ損失許容度（どこまで失ってよいか）のトレードオフを、パラメータ選択として具体的に判断できる深さが問われます。

1.4.1ストリーミングレプリケーションの構築パラメータ

• wal_level＝WALにどこまでの情報を書き込むかを決める設定。レプリケーションには最低でも replica が必要（ロジカルレプリケーションを使うなら logical）。max_wal_senders＝同時に接続できるスタンバイ/レプリケーションクライアントの上限数（walsenderプロセスの上限）。
• synchronous_standby_names＝どのスタンバイを同期レプリケーションの対象にするかを名前・優先順位・グループで指定するパラメータ（例：'FIRST 1 (standby1, standby2)'）。synchronous_commit＝コミット確定までにどの段階の確認を待つかを制御する（on＝同期スタンバイのWAL書き込み確認まで待つ・remote_write＝スタンバイのOS書き込みまで・off＝ローカルのみ）。
• hot_standby_feedback＝スタンバイ側で実行中の長時間クエリの情報をプライマリへフィードバックし、プライマリの VACUUM がそのクエリに必要な古い行バージョンを消してしまう（レプリケーション競合によるクエリキャンセル）のを防ぐ設定。副作用としてプライマリ側の肥大化が進みやすくなるトレードオフがある。

1.4.2ロジカルレプリケーションの操作

• パブリッシャ側＝CREATE PUBLICATION（レプリケーション対象のテーブル集合を定義：CREATE PUBLICATION pub1 FOR TABLE orders, customers; や FOR ALL TABLES）。ALTER PUBLICATION（対象テーブルの追加/削除）・DROP PUBLICATION（削除）。
• サブスクライバ側＝SUBSCRIPTION（CREATE SUBSCRIPTION sub1 CONNECTION '...' PUBLICATION pub1; で接続先とパブリケーションを指定して購読を開始。作成時に初期データコピーも自動実行される）。物理レプリケーションと異なりテーブル単位で選択的に同期でき、双方向・複数ソースからの集約も構成できる。
• ロジカルレプリケーションは DDL を自動伝播しない（スキーマ変更は手動で両側に適用）・シーケンス値やLARGE OBJECTは対象外、という物理レプリケーションとの違いを押さえる。

1.4.3監視ビューとプロセス

• pg_stat_replication＝プライマリ側で確認するビュー。接続中の各スタンバイについて sent_lsn（送信済みWAL位置）・write_lsn・flush_lsn・replay_lsn（適用済み位置）・sync_state（sync/potential/async）を1行ずつ表示し、遅延量やどのスタンバイが同期対象かを確認できる。
• pg_stat_wal_receiver＝スタンバイ側で確認するビュー。受信元プライマリの接続情報や受信済みWAL位置（received_lsn）を表示する。プライマリ視点の pg_stat_replication と対をなす。
• プロセス＝walsender（プライマリ側でスタンバイごとにフォークされ WAL を送信するプロセス。max_wal_senders の上限に含まれる）・walreceiver（スタンバイ側で WAL を受信し適用するプロセス）。pg_receivewal＝WALをストリーミングで受信してファイルとして保存する専用クライアントツール（アーカイブ用途・スタンバイを構築せずWALだけ集めたい場合に使う）。

ゼロからストリーミングレプリケーションを構築する流れを追いましょう。まずプライマリの postgresql.conf で wal_level = replica・max_wal_senders = 10 程度を設定し、pg_hba.conf にスタンバイからの replication 接続を許可する行を追加します。スタンバイの作成は pg_basebackup -h primary_host -D /var/lib/pgsql/data -U replicator -P -R のように行い、-R オプションで standby.signal と接続情報（primary_conninfo）が自動生成されます。可用性要件が高く「1件もデータを失いたくない」場合は、synchronous_standby_names = 'FIRST 1 (standby1)' を設定し、synchronous_commit = on のままにすることで、プライマリのコミットは standby1 がWALを書き込み確認するまで応答を返さない同期レプリケーションにします（代償としてコミットのレイテンシが増える）。逆に性能優先なら synchronous_commit = off や非同期構成を選びます。スタンバイで長時間の集計クエリを流す運用があるなら、プライマリの VACUUM がそのクエリに必要な行を消してクエリがキャンセルされるレプリケーション競合を避けるため hot_standby_feedback = on を設定します。 構築後の監視はプライマリで SELECT application_name, sync_state, replay_lsn FROM pg_stat_replication; を定期実行し、sync_state が期待通り sync になっているか、sent_lsn と replay_lsn の差から遅延が大きくなっていないかを確認します。スタンバイ側では SELECT status, received_lsn FROM pg_stat_wal_receiver; で受信状況を確認します。ロジカルレプリケーションで特定テーブルだけを別システムへ流したい場合は、パブリッシャ側で CREATE PUBLICATION sales_pub FOR TABLE orders; を作成し、サブスクライバ側で CREATE SUBSCRIPTION sales_sub CONNECTION 'host=pub_host dbname=sales user=repl' PUBLICATION sales_pub; を実行すると、作成時点の初期データコピーに続けて継続的な変更が流れ始めます。後で対象テーブルを追加したいときは ALTER PUBLICATION sales_pub ADD TABLE customers; としますが、新しい列を追加するような DDL 変更はロジカルレプリケーションでは自動伝播されないため、パブリッシャ・サブスクライバの両方に個別に適用する運用ルールを徹底します。WALだけを専用にアーカイブしたい場合は pg_receivewal -D /archive/wal -h primary_host のようにストリーミング受信を回しっぱなしにします。

1.4.4この節のまとめ

• ストリーミング構築＝wal_level=replica（ロジカルはlogical）・max_wal_senders・synchronous_standby_names・synchronous_commit・hot_standby_feedbackの組み合わせで可用性/性能/データ損失許容度を調整
• ロジカルはパブリッシャ側CREATE/ALTER/DROP PUBLICATION・サブスクライバ側SUBSCRIPTION。DDLは自動伝播しない
• 監視はプライマリ側pg_stat_replication／スタンバイ側pg_stat_wal_receiver。プロセスはwalsender/walreceiver、WAL専用収集はpg_receivewal