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

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

このガイドでは、pg_basebackup、pg_hba.conf、およびスタンバイシグナルファイルを使用した非同期ストリーミングレプリケーションについて説明します。最終的には、動作するプライマリ-スタンバイペアと、実際にストリーミングされていることを確認するためのチェックが完了します。

前提条件と環境設定

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

サーバー	役割	IPアドレス（例）
プライマリ	信頼できる情報源	192.168.1.10
スタンバイ	レプリカ	192.168.1.11

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

ステップ1：プライマリサーバーの構成

プライマリサーバーは、レプリケーション用のWALファイルを生成して提供するように構成する必要があります。

1.1 postgresql.confの変更

メイン設定ファイルを編集します。DebianおよびUbuntuパッケージでは、これは多くの場合/etc/postgresql/<version>/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に接続
sudo -u postgres psql -c "CREATE ROLE replica_user WITH REPLICATION LOGIN PASSWORD '実際の秘密のパスワードを使用';"

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

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

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

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

構成の変更を適用します。listen_addressesを変更した後は、再起動が簡単なオプションです。pg_hba.confのみを変更した場合は、リロードで十分です。

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ファイルを作成し、primary_conninfo設定を入力します。これは通常、データディレクトリ内の生成された設定ファイルpostgresql.auto.confにあります。

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 ('データが正常に同期されました');

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

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

データがスタンバイに表示される場合、ストリーミングレプリケーションが正常に構成され、アクティブになっています。

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

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

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

プライマリで：

SELECT * FROM pg_create_physical_replication_slot('standby_slot_name');

次に、スタンバイでprimary_slot_nameを設定します。スロット名をprimary_conninfo内に配置しないでください。

primary_conninfo = 'host=192.168.1.10 user=replica_user password=実際の秘密のパスワードを使用 application_name=standby_node'
primary_slot_name = 'standby_slot_name'

警告： レプリケーションスロットは注意深い監視が必要です。スタンバイが長期間障害が発生した場合、スロットによって保護された蓄積されたWALファイルにより、プライマリサーバーのディスク容量が急速に満杯になる可能性があります。

一般的な問題のトラブルシューティング

問題	潜在的な原因	解決策
スタンバイが接続できない	ネットワークファイアウォール、誤ったlisten_addresses、またはプライマリのpg_hba.confが正しくない。	ポート5432に到達可能であることを確認。pg_hba.confがスタンバイIPとユーザーと一致していることを確認。
pg_basebackupが認証エラーで失敗する	パスワードが正しくない、またはpg_hba.confにホストエントリがない。	replica_userのパスワードを再確認。pg_hba.confを変更した後、プライマリデータベースが再起動されていることを確認。
スタンバイが読み取り専用である	これは期待される動作です。	standby.signalの存在により、サーバーがリカバリモードになります。

次のステップ

ストリーミングレプリケーションの設定は、復元力のあるPostgreSQLアーキテクチャを構築するための重要なステップです。これらの手順に従うことで、継続的なデータ同期を保証するプライマリ-スタンバイペアを正常に構成でき、システムの高可用性機能が大幅に向上します。次の論理的なステップは、監視ソリューションとフェイルオーバーメカニズム（PatroniやRepmgrなど）を統合して、HAセットアップを完全に自動化することです。