PostgreSQL 18 冗長化入門：ストリーミングレプリケーション構築



データベースを単一サーバー（シングルノード）で運用している場合、ハードウェア故障や電源障害、OSパッチ適用に伴う再起動などのイベントが発生すると、システム全体のサービス停止（ダウンタイム）に直結します。この単一障害点（SPOF: Single Point of Failure）を排除し、システムの可用性と耐障害性を高めるための基礎技術が、PostgreSQL標準の機能であるStreaming Replication（ストリーミング・レプリケーション）です。

レプリケーションを導入することで、本番データを常時スタンバイサーバーへリアルタイム複製できるだけでなく、読み取りクエリをスタンバイへ逃がす「参照負荷分散（リードレプリカ運用）」も実現可能となります。

本記事では、冗長化の第一歩となるプライマリ・スタンバイ2台構成の構築手順と、実務で不可欠となる運用監視クエリを体系的に解説します。

1. Streaming Replication のアーキテクチャと動作原理#

PostgreSQLのStreaming Replicationは、データベースの更新履歴であるWAL（Write-Ahead Logging: 先行書き込みログ）をネットワーク経由でリアルタイム転送し、スタンバイ側で連続的に再生（リプレイ）する仕組みです。

1.1 プライマリとスタンバイの役割分担#

標準的なStreaming Replication構成における各ノードの役割は明確に分離されています。

• プライマリサーバー（Primary / 主系）：読み取り（SELECT）および書き込み（INSERT / UPDATE / DELETE）の双方を受け付けます。データの変更が発生するたびにWALレコードを生成し、ローカルディスクへコミットすると同時にスタンバイへ送出します。
• スタンバイサーバー（Standby / 従系 / リードレプリカ）：プライマリから送られてくるWALを順次適用し、プライマリと同一のデータ状態を維持します。通常時は読み取り専用（ReadOnly）として動作し、参照クエリの負荷分散を担います。スタンバイに対して直接更新クエリを実行することはできません。

1.2 WAL転送の内部プロセス#

レプリケーションの通信は、プライマリ側とスタンバイ側の専用バックグラウンドプロセスによって制御されます。

このパイプライン構造により、プライマリでコミットされたトランザクションは通常数ミリ秒以内の極めて微小な遅延でスタンバイ側に反映されます。

1.3 非同期レプリケーション vs 同期レプリケーション#

Streaming Replicationには「非同期（Asynchronous）」と「同期（Synchronous）」の2つの動作モードが存在します。

• 非同期レプリケーション（デフォルト・実務推奨）：プライマリはローカルディスクへのWAL書き込みが完了した時点でクライアントへトランザクション完了（COMMIT）を応答します。スタンバイへの転送完了を待機しないため、ネットワーク遅延の影響を受けず、プライマリの書き込み性能が最大化されます。万一のプライマリ障害時には、未転送のトランザクションがわずかに失われる可能性（RPO > 0）があります。
• 同期レプリケーション（synchronous_commit有効時）：プライマリはスタンバイ側でのWAL受信・ディスク書き込み完了通知を受け取るまでクライアントへのコミット応答を保留します。プライマリが突発停止してもデータ喪失がゼロ（RPO = 0）に抑えられますが、ネットワークラウンドトリップ時間の分だけトランザクション応答時間が長くなります。

Webサービスや社内情報システム、一般的な業務アプリケーションでは、パフォーマンスと耐障害性のバランスから非同期レプリケーションが標準的に採用されます。

2. 構築前のネットワーク・認証・パラメータ設計#

Streaming Replicationを構築するにあたり、プライマリ側で事前に施すべき3つの設計ポイントが存在します。

2.1 レプリケーション専用ロールの作成#

プライマリへのレプリケーション接続には、通常のデータベースアクセス権限ではなく、専用の REPLICATION 属性を持つロールを使用します。

-- プライマリ側で実行
CREATE ROLE repuser WITH REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_secret_pass';

SUPERUSER 権限を付与することなく、レプリケーション通信に必要な最小限の権限のみを付与することで、セキュリティを担保します。

2.2 pg_hba.conf での replication 接続許可#

PostgreSQLでは、通常のデータベース（all）とレプリケーション通信（replication）の認証ルールが分離されています。スタンバイのIPアドレスからの replication 疑似データベースへのアクセスを許可します。

# pg_hba.conf への追記設定例
# TYPE  DATABASE        USER     ADDRESS             METHOD
host    replication     repuser  192.168.2.135/32    scram-sha-256

接続元をスタンバイのIPアドレス（/32）に厳密に絞り込むことが実務上のセキュリティ原則です。

2.3 postgresql.conf の必須パラメータ#

PostgreSQL 18において、レプリケーションに関わる基本パラメータを確認します。

3. pg_basebackup -R による初期スタンバイ生成の内部動作#

スタンバイサーバーを立ち上げるためには、プライマリサーバーのデータディレクトリ（データブロックおよびWALログ）の完全な物理コピーを初期配置する必要があります。この処理を一括実行するツールが pg_basebackup です。

3.1 物理クラスタ複製の仕組み#

pg_basebackup は、プライマリのストレージ領域を直接ファイルコピーするのではなく、PostgreSQLのレプリケーションプロトコル経由でプライマリからデータブロック群をストリーミング受信します。データベースのオンライン稼働中であっても、整合性を保ったベースバックアップを採取できます。

3.2 -R オプションが自動生成するもの#

pg_basebackup の実行時に -R（または --write-recovery-conf）オプションを指定すると、単なるバックアップに留まらず、スタンバイとして起動するための設定ファイルを自動生成します。

1. standby.signal ファイルの生成：
   データディレクトリ直下に0バイトの空ファイル standby.signal を作成します。PostgreSQLサーバーはこのファイルが存在する場合、通常モードではなく「スタンバイ（リカバリ）モード」として起動します。
2. postgresql.auto.conf への primary_conninfo 追記：
   pg_basebackup 実行時に使用した接続情報（ホスト名、ポート、ユーザー名、パスワード等）を元に、プライマリへの接続文字列を primary_conninfo パラメータとして設定ファイルへ自動追記します。

3.3 -c fast（チェックポイント即時完了）の必須性#

実務で pg_basebackup を実行する際、必ず付与すべきオプションが -c fast（--checkpoint=fast）です。

デフォルト動作では、プライマリ側のI/Oスパイクを避けるために通常のチェックポイント完了を待機するため、バックアップ開始までに数十秒から数分間処理がスタックします。-c fast を指定することで、プライマリに対して即時チェックポイントの実行を指示し、待機時間ゼロでバックアップ処理を開始できます。

4. 実務標準：Streaming Replication 構築の6ステップワークフロー#

2台のサーバーを用いてレプリケーション環境を無駄なく構築するための標準手順を提示します。

5. 【実機検証】AlmaLinux 10での Streaming Replication 構築実践#

実機検証環境の2台（プライマリ: alma-db01 / スタンバイ: alma-db02）を用いて、実際に非同期Streaming Replicationを構築したログと検証結果を提示します。

5.1 検証環境構成#

• プライマリ（Primary）：alma-db01（IP: 192.168.2.132 / AlmaLinux 10.2 / PostgreSQL 18.6）
• スタンバイ（Standby）：alma-db02（IP: 192.168.2.135 / AlmaLinux 10.2 / PostgreSQL 18.6）

5.2 プライマリ側の設定と初期データ作成#

プライマリ側で初期設定とテストテーブルの作成を行います。

# 1. 外部接続と認証ルールの設定
$ sudo sed -i "s/#listen_addresses = 'localhost'/listen_addresses = '*'/g" /var/lib/pgsql/18/data/postgresql.conf
$ echo "host replication repuser 192.168.2.135/32 scram-sha-256" | sudo tee -a /var/lib/pgsql/18/data/pg_hba.conf
$ echo "host all all 192.168.2.0/24 scram-sha-256" | sudo tee -a /var/lib/pgsql/18/data/pg_hba.conf

# 2. ファイアウォール開放とサービス起動
$ sudo firewall-cmd --add-service=postgresql --permanent && sudo firewall-cmd --reload
$ sudo systemctl enable --now postgresql-18

# 3. レプリケーションロールの作成とテストデータ投入
$ sudo -u postgres /usr/pgsql-18/bin/psql -c "CREATE ROLE repuser WITH REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_secret_pass';"
$ sudo -u postgres /usr/pgsql-18/bin/psql -c "CREATE DATABASE production_db;"
$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "
CREATE TABLE public.cluster_nodes (
    node_id serial PRIMARY KEY,
    hostname text NOT NULL,
    role text NOT NULL,
    ip_address inet NOT NULL,
    registered_at timestamptz DEFAULT current_timestamp
);
INSERT INTO public.cluster_nodes (hostname, role, ip_address) VALUES
    ('alma-db01', 'Primary', '192.168.2.132'),
    ('alma-db02', 'Standby', '192.168.2.135');
"

# 4. 物理レプリケーションスロットの事前作成（プライマリ側）
$ sudo -u postgres /usr/pgsql-18/bin/psql -c "SELECT pg_create_physical_replication_slot('standby_slot_01');"
 pg_create_physical_replication_slot 
-------------------------------------
 (standby_slot_01,)
(1 行)

5.3 スタンバイ側での pg_basebackup -R 実行#

スタンバイ（alma-db02）にログインし、空のデータディレクトリに対して事前作成したレプリケーションスロット（standby_slot_01）を指定してベースバックアップを実行します。

$ sudo -u postgres PGPASSWORD='rep_secret_pass' /usr/pgsql-18/bin/pg_basebackup \
  -h 192.168.2.132 \
  -p 5432 \
  -U repuser \
  -D /var/lib/pgsql/18/data \
  -Fp \
  -Xs \
  -c fast \
  -S standby_slot_01 \
  -P \
  -R -v

実行ログ（実測結果）：

pg_basebackup: ベースバックアップを開始しています - チェックポイントの完了を待機中
pg_basebackup: チェックポイントが完了しました
pg_basebackup: 先行書き込みログの開始ポイント: タイムライン 1 上の 0/3000028
pg_basebackup: バックグランドWAL受信処理を起動します
pg_basebackup: レプリケーションスロット"standby_slot_01"を使用しています
31386/31386 kB (100%), 0/1 テーブル空間 (.../pgsql/18/data/global/pg_control)
31386/31386 kB (100%), 1/1 テーブル空間                                         
pg_basebackup: 先行書き込みログの終了ポイント: 0/3000120
pg_basebackup: バックグランドプロセスがストリーミング処理が終わるまで待機します ...
pg_basebackup: データをディスクに同期しています...
pg_basebackup: backup_manifest.tmp の名前を backup_manifest に変更しています
pg_basebackup: ベースバックアップが完了しました

所要時間はわずか1秒でした。生成されたファイルを確認します。

# standby.signal の存在確認（サイズ0バイト）
$ sudo ls -la /var/lib/pgsql/18/data/standby.signal
-rw-------. 1 postgres postgres 0  9月  9 23:02 /var/lib/pgsql/18/data/standby.signal

# postgresql.auto.conf に追記された接続情報とスロット設定
$ sudo cat /var/lib/pgsql/18/data/postgresql.auto.conf
# Do not edit this file manually!
# It will be overwritten by the ALTER SYSTEM command.
primary_conninfo = 'user=repuser password=rep_secret_pass host=192.168.2.132 port=5432 ...'
primary_slotname = 'standby_slot_01'

5.4 スタンバイ起動と接続ステータス確認#

スタンバイのPostgreSQLサービスを起動し、ログを確認します。

$ sudo firewall-cmd --add-service=postgresql --permanent && sudo firewall-cmd --reload
$ sudo systemctl enable --now postgresql-18

スタンバイ起動ログ（/var/lib/pgsql/18/data/log/postgresql-Wed.log）：

LOG:  スタンバイモードに入ります
LOG:  REDOを0/3000028から開始します
LOG:  0/3000120 でリカバリの一貫性が確保されました
LOG:  データベースシステムはリードオンリー接続の受け付け準備ができました
LOG:  プライマリのタイムライン1の 0/4000000からでWALストリーミングを始めます

スタンバイ側で関数を実行し、リカバリ中であることを確認します。

$ sudo -u postgres /usr/pgsql-18/bin/psql -c "SELECT pg_is_in_recovery();"
 pg_is_in_recovery 
-------------------
 t
(1 行)

$ sudo -u postgres /usr/pgsql-18/bin/psql -x -c "SELECT pid, status, receive_start_lsn, written_lsn, flushed_lsn, sender_host, sender_port FROM pg_stat_wal_receiver;"
-[ RECORD 1 ]-----+------------
pid               | 6818
status            | streaming
receive_start_lsn | 0/4000000
written_lsn       | 0/404DFA0
flushed_lsn       | 0/404DFA0
sender_host       | 192.168.2.132
sender_port       | 5432

5.5 プライマリ側ビューによる同期状態と遅延の監視#

プライマリ（alma-db01）からレプリケーションビュー pg_stat_replication を照合します。

$ sudo -u postgres /usr/pgsql-18/bin/psql -x -c "SELECT pid, usename, application_name, client_addr, state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn FROM pg_stat_replication;"
-[ RECORD 1 ]----+--------------
pid              | 3723
usename          | repuser
application_name | walreceiver
client_addr      | 192.168.2.135
state            | streaming
sync_state       | async
sent_lsn         | 0/404DFA0
write_lsn        | 0/404DFA0
flush_lsn        | 0/404DFA0
replay_lsn       | 0/404DFA0

レプリケーション遅延（Replication Lag）をバイト数で算出するクエリを実行します。

$ sudo -u postgres /usr/pgsql-18/bin/psql -c "
SELECT
    client_addr,
    application_name,
    state,
    sync_state,
    pg_current_wal_lsn() AS current_wal_lsn,
    replay_lsn,
    pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;
"
  client_addr  | application_name |   state   | sync_state | current_wal_lsn | replay_lsn | replication_lag_bytes 
---------------+------------------+-----------+------------+-----------------+------------+-----------------------
 192.168.2.135 | walreceiver      | streaming | async      | 0/404DFA0       | 0/404DFA0  |                     0
(1 行)

replication_lag_bytes が 0 であり、完全同期を維持していることが確認できました。

5.5.1 レプリケーションスロットの健全性監視（pg_replication_slots）#

ストリーミングレプリケーション運用において、pg_stat_replication と並んで監視が必須となるのがシステムビュー pg_replication_slots です。

$ sudo -u postgres /usr/pgsql-18/bin/psql -x -c "SELECT slot_name, slot_type, active, restart_lsn, wal_status FROM pg_replication_slots;"
-[ RECORD 1 ]+----------------
slot_name    | standby_slot_01
slot_type    | physical
active       | t
restart_lsn  | 0/404DFA0
wal_status   | reserved

ここで着目すべきは active 列と wal_status 列です。active が t（true）であればスタンバイノードが現在接続中であることを示します。もしスタンバイ停止やネットワーク断により active が f（false）になった場合、プライマリはスタンバイ復旧に備えてWALセグメントをディスク内に蓄積し続けます。監視システムでは active = f の継続時間、および wal_status = lost（未転送WALが溢れてレプリケーションが破綻した状態）の検知アラートを必ず設定します。

5.5.2 同期レプリケーション（synchronous_commit）の設計基準#

本稿で構築した構成は「非同期（async）レプリケーション」です。実務の要件（RPO: 目標復旧時点）に応じて、プライマリの synchronous_commit パラメータを調整することでデータ保護レベルを段階的に強化できます。

# 1. スタンバイ側（/var/lib/pgsql/18/data/postgresql.auto.conf 等）
primary_conninfo = 'host=192.168.2.132 port=5432 user=repuser application_name=standby01 password=...'

# 2. プライマリ側（/var/lib/pgsql/18/data/postgresql.conf）
synchronous_standby_names = 'FIRST 1 (standby01)' # 未設定時はリモート待機が無効化される

# 3. プライマリで設定反映
$ sudo systemctl reload postgresql-18

5.6 同期整合性とリードレプリカ保護の実証#

プライマリにデータを追加し、スタンバイで即座に参照できるかを検証します。

# プライマリ（alma-db01）でデータ追加
$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "
INSERT INTO public.cluster_nodes (hostname, role, ip_address) VALUES ('alma-db03', 'Standby-2', '192.168.2.136');
"

# スタンバイ（alma-db02）で即座に照会
$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "SELECT * FROM public.cluster_nodes;"
 node_id | hostname  |   role    |  ip_address   |         registered_at         
---------+-----------+-----------+---------------+-------------------------------
       1 | alma-db01 | Primary   | 192.168.2.132 | 2026-09-09 23:00:48.536817+09
       2 | alma-db02 | Standby   | 192.168.2.135 | 2026-09-09 23:00:48.536817+09
       3 | alma-db03 | Standby-2 | 192.168.2.136 | 2026-09-09 23:03:00.816757+09
(3 行)

プライマリでの追加が即時にスタンバイへ伝播していることが確認できました。次にスタンバイに対して更新クエリを試行します。

# スタンバイ（alma-db02）での書き込み試行
$ sudo -u postgres /usr/pgsql-18/bin/psql -d production_db -c "
INSERT INTO public.cluster_nodes (hostname, role, ip_address) VALUES ('test-fail', 'Invalid', '192.168.2.99');
"
ERROR:  リードオンリーのトランザクションでは INSERT を実行できません

データベースエンジンにより書き込みが厳格に拒絶され、データの不整合が防止されていることを実証できました。

6. 実務チートシート：レプリケーション遅延監視クエリとトラブルシューティング#

実務の現場で直面する運用監視とトラブルシューティングのためのチートシートです。

6.1 詳細遅延監視クエリ（送信・ディスク書込・フラッシュ・再生）#

レプリケーションの遅延には4段階のフェーズが存在します。それぞれのボトルネックを特定する監視クエリです。

SELECT
    client_addr AS standby_ip,
    application_name,
    state,
    sync_state,
    pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn)   AS send_lag_bytes,
    pg_wal_lsn_diff(sent_lsn, write_lsn)              AS write_lag_bytes,
    pg_wal_lsn_diff(write_lsn, flush_lsn)             AS flush_lag_bytes,
    pg_wal_lsn_diff(flush_lsn, replay_lsn)            AS replay_lag_bytes,
    pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS total_lag_bytes,
    replay_lag
FROM pg_stat_replication;

• send_lag_bytes が大きい場合：ネットワーク帯域不足、またはプライマリの walsender 負荷が高い。
• flush_lag_bytes が大きい場合：スタンバイ側のディスク書き込みI/O性能が不足。
• replay_lag_bytes が大きい場合：スタンバイ側で重い参照クエリが実行されており、WAL再生と競合（ロック競合）している。

6.2 よくあるトラブルと対処マトリクス#

7. 理解度確認演習問題（全3問・解答解説付き）#

本記事で解説したStreaming Replicationのアーキテクチャと運用知識を定着させるための確認問題です。

8. まとめとシリーズ完結#

本記事をもって、「現場で迷わない PostgreSQL環境構築・運用シリーズ」全10回（第00回〜第09回）は完結となります。第01回のアーキテクチャ基礎から始まり、インストール選定、設定チューニング、アクセス制御、権限設計、物理・論理バックアップ、VACUUM内部機構、マイナーおよびメジャーバージョンアップ、そしてストリーミングレプリケーションによるクラスタ冗長化まで、本番運用に必要な実務知識を網羅しました。

リンク