PostgreSQLストリーミングレプリケーション設定のステップバイステップガイド

ストリーミングレプリケーションは、PostgreSQL環境における高可用性（HA）と読み取りスケーラビリティを実現するための基本的なメカニズムです。プライマリ（マスター）サーバーを設定し、Write-Ahead Log（WAL）レコードを1つ以上のスタンバイ（レプリカ）サーバーに継続的にストリーミングすることで、最小限の遅延でデータの同期を確保します。

この包括的なガイドでは、堅牢な非同期ストリーミングレプリケーションを確立するために必要な不可欠なステップを順を追って説明します。pg_basebackupやシグナルファイルといった最新のPostgreSQL機能を利用して、プライマリサーバーとスタンバイサーバーの両方で必要な設定変更をカバーし、セットアップを簡素化します。このチュートリアルに従うことで、堅牢なPostgreSQL運用のための信頼できる基盤を身につけることができます。

前提条件と環境設定

開始する前に、以下の前提条件が満たされていることを確認してください。このガイドでは、プライマリとスタンバイの2つのサーバーがあり、両方とも同じメジャーバージョンのPostgreSQL（バージョン12以降を推奨）を実行していることを前提とします。

サーバー	役割	IPアドレス（例）
プライマリ	真実の情報源	192.168.1.10
スタンバイ	レプリカ	192.168.1.11

ユーザー: 両方のサーバーで管理者アクセス権（例：sudoまたはpostgresシステムユーザー）が必要です。
ネットワーク: スタンバイサーバーは、PostgreSQLポート（デフォルトは5432）でプライマリサーバーに接続できる必要があります。

ステップ1：プライマリサーバーの設定

プライマリサーバーは、レプリケーションのためにWALファイルを生成および提供するように設定する必要があります。

1.1 `postgresql.conf`の変更

通常、データディレクトリ（例：/etc/postgresql/14/main/postgresql.conf）にあるメイン設定ファイルを編集し、以下のパラメータを設定します。

# 他のホストからの接続を許可
listen_addresses = '*'

# WALレベルを 'replica' 以上に設定
wal_level = replica

# スタンバイサーバーからの同時接続の最大数
max_wal_senders = 5 

# 同時にアクティブにできるスタンバイ接続数を制御
max_replication_slots = 5

# スタンバイでの読み取り専用クエリに必要（ホットスタンバイ）
hot_standby = on

1.2 専用レプリケーションユーザーの作成

セキュリティのため、REPLICATION属性を持つ特定のユーザーを作成します。このユーザーは、WALレコードを取得するためにスタンバイサーバーのみによって使用されます。

# PostgreSQLに接続
psql -c "CREATE USER replica_user REPLICATION ENCRYPTED PASSWORD 'SuperSecurePassword123';"

1.3 クライアント認証（`pg_hba.conf`）の更新

スタンバイサーバーのIPアドレスからレプリケーションユーザーが、特別なreplication疑似データベースに接続できるようにします。

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replica_user    192.168.1.11/32         md5

1.4 プライマリサーバーの再起動

PostgreSQLサービスを再起動して変更を適用します。

sudo systemctl restart postgresql

ステップ2：スタンバイサーバーの準備

データをクローンする前に、スタンバイのPostgreSQLサービスが停止しており、既存のデータディレクトリがクリアされていることを確認してください。

2.1 スタンバイPostgreSQLサービスの停止

sudo systemctl stop postgresql

2.2 データディレクトリのクリア

警告：このステップは、スタンバイのデータディレクトリにあるすべてのデータを永久に削除します。実行前にパスを確認してください。

# PG 14の例のパス
PG_DATA=/var/lib/postgresql/14/main

sudo rm -rf $PG_DATA/*

2.3 `pg_basebackup`を使用したデータクローン

pg_basebackupを使用して、プライマリのデータディレクトリの正確なコピーを作成します。-Rフラグは、ストリーミングレプリケーション（PostgreSQL 12以降）に必要な設定ファイル（standby.signalとprimary_conninfo）を自動生成するため、非常に重要です。

スタンバイサーバーでこのコマンドを実行します。

PG_DATA=/var/lib/postgresql/14/main

sudo -u postgres pg_basebackup -h 192.168.1.10 -D $PG_DATA -U replica_user -P -v -R

オプション	説明
`-h`	プライマリサーバーのホスト名/IPアドレス。
`-D`	ローカルのデータディレクトリパス。
`-U`	レプリケーションユーザー名（`replica_user`）。
`-P`	進捗を表示。
`-v`	詳細な出力を表示。
`-R`	レプリケーション設定ファイルを自動作成。

ステップ3：スタンバイの設定と起動

3.1 スタンバイ設定の検証

ステップ2.3で-Rフラグを使用した場合、pg_basebackupはstandby.signalファイルを作成し、通常はデータディレクトリ内のpostgresql.auto.confという名前の生成された設定ファイルにprimary_conninfo設定を格納しました。

primary_conninfo文字列の内容を確認してください。以下のようなものになっているはずです（$PG_DATA/postgresql.auto.conf内を確認してください）：

primary_conninfo = 'host=192.168.1.10 user=replica_user password=SuperSecurePassword123 application_name=standby_node'

ヒント： パスワードがprimary_conninfoに含まれているか、証明書ベースの認証を使用していることを確認してください。pg_hba.confでtrustまたはcertを使用している場合、パスワードは省略されることがあります。

3.2 スタンバイサービスの起動

必要なシグナルファイル（standby.signal）がデータディレクトリに存在するため、サービスは読み取り専用スタンバイモードで起動し、すぐにプライマリへの接続を試みます。

sudo systemctl start postgresql

ステップ4：ストリーミングレプリケーションの検証

スタンバイを起動した後、接続がアクティブであり、データ同期が発生していることを確認する必要があります。

4.1 プライマリサーバーでの検証

プライマリサーバーに接続し、pg_stat_replicationビューをクエリします。スタンバイサーバーからの接続を表す行が表示されるはずです。

psql -c "SELECT client_addr, state, sync_state, sent_lsn, write_lsn, flush_lsn FROM pg_stat_replication;"

期待される出力（主要フィールド）：

client_addr：スタンバイサーバーのIP（例：192.168.1.11）と一致するはずです。
state：streamingであるべきです。startupまたはcatching upと表示される場合は、しばらく待ってください。walsenderが起動中と表示される場合は、あと一歩です。
sync_state：async（標準の非同期レプリケーションの場合）であるべきです。

4.2 データ同期のテスト

データフローを確認するために、プライマリで変更を実行し、すぐにスタンバイでその存在を確認します。

プライマリで：

CREATE TABLE replication_test (id serial primary key, message text);
INSERT INTO replication_test (message) VALUES ('Data synchronized successfully');

スタンバイで（読み取り専用）：

-- これはエラーなしで成功する必要があります
psql -c "SELECT * FROM replication_test;"

データがスタンバイで表示されれば、ストリーミングレプリケーションは正常に設定され、アクティブです。

ベストプラクティスとトラブルシューティング

永続的な接続：レプリケーションスロット

オプションですが、レプリケーションスロットは強く推奨されます。レプリケーションスロットは、スタンバイが一時的に切断された場合でも、プライマリサーバーがスタンバイに必要なWALセグメントを早期に破棄しないことを保証します。