レプリケーションの諸機能と、同期接続

BCP／DR

技術解説

連載 :

PostgreSQLとストリーミング・レプリケーション

2011年10月27日(木)

那賀樹一郎（なかきいちろう）

同期レプリケーションへの変更

まずは、前回までの非同期レプリケーションの処理の流れの概要を見てみます。

図2：非同期での処理の流れ

実行の順序を見ていただくと分かる通り、プライマリがローカルのディスクへ WAL を書き出し終えたところで、クライアントへはコミットの成功を返し、その後で、クライアントの操作とは全く非同期に、スタンバイ側への WAL レコードの転送とディスクへの書き出しを行います。

それに対して、同期レプリケーションの処理は以下のようになります。

図3：同期での処理の流れ

プライマリのディスクに WAL を書き出したことを確認した後で、スタンバイへ WAL ログを送信します。そしてスタンバイも WAL をディスクへ書き出したことを確認できたら、ようやくクライアントへコミットの成功を返します。パフォーマンスと引き換えに、データの保護を優先した構成と言うことができます。

それでは、前回の非同期レプリケーションの構成を、そのまま同期に変更して行きましょう。~postgres/pgdata-prim/postgresql.conf を下記のように修正し、同期スタンバイになるノードの application_name を指定します。

1synchronous_standby_names = ''
2 
3  ↓
4 
5synchronous_standby_names = 'stby'

修正し終えたら、プライマリ、スタンバイ共に再起動します。

01-bash-4.1$ pg_ctl -D ~/pgdata-prim restart
02サーバ停止処理の完了を待っています....完了
03サーバは停止しました
04サーバは起動中です。
05-bash-4.1$ pg_ctl -D ~/pgdata-stby/ restart
06サーバ停止処理の完了を待っています....完了
07サーバは停止しました
08サーバは起動中です。
09-bash-4.1$ psql -x -p 5432 -c "SELECT * FROM pg_stat_replication"
10-[ RECORD 1 ]----+------------------------------
11procpid          | 13136
12usesysid         | 16384
13usename          | reprole
14application_name | stby
15client_addr      | 127.0.0.1
16client_hostname  |
17client_port      | 42722
18backend_start    | 2011-XX-XX 16:58:58.420314+09
19state            | streaming
20sent_location    | 0/3037000
21write_location   | 0/3037000
22flush_location   | 0/3037000
23replay_location  | 0/3036FA8
24sync_priority    | 1
25sync_state       | sync
26 
27-bash-4.1$

sync_priority が "0" から "1" へ、sync_state が "async" から "sync" へと、同期でのレプリケーションを表す値に変わったのが分かるかと思います。試しに、同期スタンバイを停止させてからプライマリに書き込みを行うとどうなるかを見てみましょう。

1-bash-4.1$ pg_ctl -D ~/pgdata-stby/ stop
2サーバ停止処理の完了を待っています....完了
3サーバは停止しました
4-bash-4.1$ psql -p 5432 -c "INSERT INTO members VALUES(128, 'Hoge')" # 戻らない…
5...

このように、スタンバイ側への書き込みが確認されるまで、プライマリへの変更は確定しません。別のコンソールからスタンバイ側のノードをスタートさせれば、上記のクエリは成功します。

メンテナンスなどのためにプライマリを単体で起動させたい場合には、一時的に synchronous_commit パラメータを "local" にすることで、スタンバイへの同期レプリケーションができなくても処理が返るようになります。

01-bash-4.1$ pg_ctl -D ~/pgdata-stby/ stop # スタンバイの停止
02サーバ停止処理の完了を待っています....完了
03サーバは停止しました
04-bash-4.1$ pg_ctl -D ~/pgdata-prim/ -o "-c synchronous_commit=local" restart
05サーバ停止処理の完了を待っています....完了
06サーバは停止しました
07サーバは起動中です。
08-bash-4.1$ psql -p 5432 -c "INSERT INTO members VALUES(256, 'Fuga')" # 戻る
09INSERT 0 1
10-bash-4.1$ pg_ctl -D ~/pgdata-prim/ -o "-c synchronous_commit=on" restart
11サーバ停止処理の完了を待っています....完了
12サーバは停止しました
13サーバは起動中です。
14-bash-4.1$ psql -p 5432 -c "INSERT INTO members VALUES(512, 'Hare')" # 戻らない…

最後に、プライマリノードを終了手続きを経ずに異常終了させ、それまでのスタンバイを新プライマリに昇格させてみます。その後で、旧プライマリを新スタンバイとして、pg_basebackup コマンドによる再構築なしに、recovery_target_timeline='latest' の設定を用いることで、新プライマリに再度接続させてみます。この際、~/pgdata-stby/pg_log/ ディレクトリに出力されているテキストログを見ながら作業をすると、昇格の流れが分かりやすいかと思います。

1-bash-4.1$ pg_ctl -D ~/pgdata-prim/ -m immediate stop
2サーバ停止処理の完了を待っています...完了
3サーバは停止しました
4-bash-4.1$ pg_ctl -D ~/pgdata-stby/ promote
5サーバを昇進中です。
6-bash-4.1$

旧プライマリを新スタンバイにするために、~postgres/pgdata-prim/recovery.conf を準備します。

1standby_mode = 'on'
2primary_conninfo = 'host=localhost port=5433 user=reprole password=reppass application_name=prim'
3recovery_target_timeline = 'latest'
4restore_command = 'cp /var/lib/pgsql/pgdata-stby/pg_xlog/%f "%p" 2> /dev/null'

新スタンバイのサービスを起動します。

1-bash-4.1$ pg_ctl -D ~/pgdata-prim/ start
2サーバは起動中です。
3-bash-4.1$

レプリケーションが行われていることを確認します。

01-bash-4.1$ psql -p 5433 -c "INSERT INTO members VALUES(777, 'Foo')"
02INSERT 0 1
03-bash-4.1$ psql -p 5433 -c "SELECT * FROM members WHERE id = 777" # 新プライマリ
04 id  | name
05-----+------
06 777 | Foo
07(1 行)
08 
09-bash-4.1$ psql -p 5432 -c "SELECT * FROM members WHERE id = 777" # 新スタンバイ
10 id  | name
11-----+------
12 777 | Foo
13(1 行)
14 
15-bash-4.1$