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

次のセクションでは、ストリーミングレプリケーションを使用してマスターノードからスタンバイノードにデータをレプリケートする単純な2ノードレプリケーションシナリオを構成するプロセスについて説明します。大規模なシナリオのレプリケーションプロセスは複雑になる場合があります。構成オプションの詳細については、次から入手可能なPostgreSQLコアドキュメントを参照してください。

https://www.postgresql.org/docs/10/static/warm-standby.html#streaming-replication

次の例では、 .pgpassファイルを使用してレプリケーションユーザーのmd5認証を有効にします。これは、環境にとって最も安全な認証方法である場合とそうでない場合があります。サポートされている認証オプションの詳細については、次のPostgreSQLコアドキュメントを参照してください。

https://www.postgresql.org/docs/10/static/client-authentication.html

以下の手順では、それぞれがEDB Postgres Advanced Serverのインストールを実行する1つのマスターノードと1つのスタンバイノードを使用した単純なストリーミングレプリケーションシナリオを構成します。例では：

• マスターノードは146.148.46.44ます。
• スタンバイノードは107.178.217.178ます。
• レプリケーションユーザー名はedbrepuserです。

例で参照されているパス名とコマンドは、CentOS 6.xホスト上にあるAdvanced Serverホスト用です。構成に合わせてパスとコマンドを変更する必要がある場合があります。

マスターノードの構成

レプリケーションシナリオのマスターノードに接続し、 pg_hba.confファイル（Postgresインストールの下のデータディレクトリにあります）を変更し、レプリケーションユーザー（この例ではedbrepuser）の接続情報を追加します。

ホスト複製edbrepuser 107.178.217.178/32 md5

接続情報には、レプリケーションシナリオのスタンバイノードのアドレスと、優先する認証方法を指定する必要があります。

postgresql.confファイル（Postgresインストールの下のデータディレクトリにあります）を変更し、次のレプリケーションパラメータと値をファイルの最後に追加します。

 wal_level = hot_standby
max_wal_senders = 8
wal_keep_segments = 128
archive_mode = on
archive_command = 'cp %p /tmp/ %f '

構成ファイルを保存し、サーバーを再起動します。

/etc/init.d/edb-as10 restart

sudo su –コマンドを使用して、enterprisedbデータベースのスーパーユーザーのIDを引き継ぎます。

sudo su - enterprisedb

次に、psqlセッションを開始して、edbデータベースに接続します。

/opt/edb/as10/psql -d edb

psqlコマンドラインで、レプリケーション属性を持つユーザーを作成します。

CREATE ROLE edbrepuser WITH REPLICATION LOGIN PASSWORD 'password';

スタンバイノードの構成

スタンバイサーバーに接続し、データベーススーパーユーザー（enterprisedb）のIDを引き継ぎます。

sudo su - enterprisedb

エディターを選択して、enterprisedbユーザーのホームディレクトリに.pgpassファイルを作成します。 .pgpassファイルには、レプリケーションユーザーのパスワードがプレーンテキスト形式で保持されます。 .pgpassファイルを使用している場合、信頼できるユーザーのみが.pgpassファイルにアクセスできるようにする必要があります。

レプリケーションユーザーの接続情報を指定するエントリを追加します。

*:5444:*:edbrepuser:password

サーバーは、.pgpassファイルに制限付きアクセス許可を適用します。次のコマンドを使用して、ファイルのアクセス許可を設定します。

chmod 600 .pgpass

データベースのスーパーユーザーのIDを放棄します。

exit

次に、スーパーユーザー権限を引き継ぎます。

sudo su -

スタンバイノードのデータディレクトリをマスターノードのデータディレクトリに置き換える前に、データベースサーバーを停止する必要があります。次のコマンドを使用します。

/etc/init.d/edb-as-10 stop

次に、スタンバイノードのデータディレクトリを削除します。

rm -rf /opt/edb/as10/data

既存のデータディレクトリを削除した後、binディレクトリに移動し、pg_basebackupユーティリティを使用して、マスターノードのデータディレクトリをスタンバイにコピーします。

cd /opt/edb/as10/bin
./pg_basebackup –R –D /opt/edb/as10/data --host=146.148.46.44 –-port=5444 --username=edbrepuser --password

pg_basebackupの呼び出しは、マスターノードのIPアドレスと、マスターノードで作成されたレプリケーションユーザーの名前を指定します。 pg_basebackupユーティリティで使用可能なオプションの詳細については、次のPostgreSQLコアドキュメントを参照してください。

https://www.postgresql.org/docs/10/static/app-pgbasebackup.html

pg_basebackupによってプロンプトが表示されたら、レプリケーションユーザーに関連付けられたパスワードを入力します。

データディレクトリをコピーした後、ディレクトリの所有権をデータベーススーパーユーザー（enterprisedb）に変更します。

chown -R enterprisedb /opt/edb/as10/data

データディレクトリに移動します。

cd /opt/edb/as10/data

エディターを選択して、recovery.conf（/opt/PostgresPlus/9.xAS/dataディレクトリーに）という名前のファイルを作成します。

standby_mode = on
primary_conninfo = 'host=146.148.46.44 port=5444 user=edbrepuser
sslmode=prefer sslcompression=1 krbsrvname=postgres'
trigger_file = '/opt/edb/as10/data/mytrigger'
restore_command = '/bin/true'
recovery_target_timeline = 'latest'

primary_conninfoパラメーターは、レプリケーションシナリオのマスターノード上のレプリケーションユーザーの接続情報を指定します。

recovery.confファイルの所有権をenterprisedbに変更します。

chown enterprisedb:enterprisedb recovery.conf

postgresql.confファイル（Postgresインストールの下のデータディレクトリにあります）を変更し、ファイルの最後に次の値を指定します。

wal_level = hot_standby max_wal_senders = 8 wal_keep_segments = 128 hot_standby = on

データファイルはマスターノードからコピーされており、前に指定したレプリケーションパラメーターが含まれています。

次に、サーバーを再起動します。

/etc/init.d/edb-as-10 start

この時点で、マスターノードはスタンバイノードにデータを複製します。

マスターからスタンバイへのレプリケーションの確認

次のコマンドを入力して、サーバーが実行中で複製されていることを確認できます。

ps -ef \| grep postgres

レプリケーションが実行されている場合、スタンバイサーバーはエコーします。

501 42054 1 0 07:57 pts/1 00:00:00
/opt/PostgresPlus/9.2AS/bin/edb-postgres -D
/opt/PostgresPlus/9.2AS/data
501 42055 42054 0 07:57 ? 00:00:00 postgres: logger process
501 42056 42054 0 07:57 ? 00:00:00 postgres: startup process
000000010000000000000004 501 42057 42054 0 07:57を回復していますか？ 00:00:00 postgres：チェックポイントプロセス501 42058 42054 0 07:57？ 00:00:00 postgres：ライタープロセス501 42059 42054 0 07:57？ 00:00:00 postgres：統計情報収集プロセス501 42060 42054 0 07:57？ 00:00:00 Postgres：Wal Receiverプロセスストリーミング0/4000150 501 42068 42025 0 07:58 pts / 1 00:00:00 grep postgres 

psqlクライアントを使用してスタンバイに接続し、pg_is_in_recovery（）関数を照会すると、サーバーは応答します。

edb=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
t
(1 row)

マスターノードに対して行われたエントリは、スタンバイノードに複製されます。スタンバイノードは読み取り専用モードで動作します。スタンバイサーバーを照会することはできますが、スタンバイノードに存在するデータベースにエントリを直接追加することはできません。

手動でフェールオーバーを呼び出す

スタンバイをマスターノードに昇格させるには、クラスター所有者（enterprisedb）のIDを想定します。

sudo su - enterprisedb

次に、pg_ctlを呼び出します。

/opt/edb/as10/bin/pg_ctl promote -D / opt/edb/as10 /data/

次に、psqlでスタンバイノードに接続すると、サーバーはそれがスタンバイノードではなくなったことを確認します。

edb=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
f
(1 row)

ストリーミングレプリケーションの設定および使用の詳細については、次のURLで入手可能なPostgreSQLコアドキュメントを参照してください

https://www.postgresql.org/docs/10/static/warm-standby.html#streaming-replication

カスケード複製の限定サポート

フェールオーバーマネージャーはカスケードレプリケーションを完全にはサポートしていませんが、カスケードレプリケーションシナリオでは単純なフェールオーバーを限定的にサポートしています。カスケードレプリケーションにより、スタンバイノードは別のスタンバイノードにストリーミングできるため、マスターノードへの接続数（および処理オーバーヘッド）が削減されます。

カスケード複製。

カスケードレプリケーションの構成の詳細については、次のPostgreSQLドキュメントを参照してください。

https://www.postgresql.org/docs/10/static/warm-standby.html#cascading-replication

カスケードレプリケーションシナリオでフェールオーバーマネージャーを使用するには、クラスタープロパティファイルを変更し、スタンバイノード＃2で次のプロパティ値を設定する必要があります。

promotable=false
auto.reconfigure=false

フェールオーバーが発生すると、スタンバイノード＃1がマスターノードの役割に昇格します。フェールオーバーが発生した場合、スタンバイノード＃2は、3つのノードを含むようにレプリケーションシナリオを手動で再構成するアクションを実行するまで、新しいマスターノードの読み取り専用レプリカとして機能し続けます。

スタンバイノード＃1に障害が発生した場合、フェールオーバー保護はありませんが、ノードの障害を通知する電子メールが届きます。

スイッチオーバーを実行して元のマスターに戻すと、カスケード複製シナリオが保持されない場合があることに注意してください。