PostgreSQL 9系の目玉、「レプリケーション機能」を試す：もう一度始めたい人のPostgreSQL（2）（2/2 ページ）

待機系サーバの設定

　続けて、待機系サーバとなるnode2サーバの設定を行います。

　node1サーバのベースバックアップを取得します。ベースバックアップの取得はpg_basebackupコマンドを用います。

[postgres@node2 ~]$ pg_basebackup -D /usr/local/pgsql/data --xlog --verbose -h node1 -U repli
Password: # repli ユーザーのパスワードを入力。今回はrepli。
transaction log start point: 0/3000020
transaction log end point: 0/30000C8
pg_basebackup: base backup completed

　-Dオプションでnode2サーバで作成するデータベースクラスタのディレクトリを指定します。このディレクトリは、あらかじめ作成しておく必要はありません。--xlogオプションでnode1サーバのトランザクションログも取得するように指定します。-hオプションでnode1サーバを指定し、-Uオプションで接続ユーザーを指定します。ここではレプリケーション専用ユーザーであるrepliを指定しましょう。また、今回は--verboseオプションを指定して詳細メッセージも出力しています。

　次に、recovery.confファイルの設定を行います。サンプルファイルがPostgreSQLのインストールディレクトリ下の"share/recovery.conf.sample"にあるので、それをデータベースクラスタディレクトリにコピーします。

[postgres@node2 ~]$ cp /usr/local/pgsql/share/recovery.conf.sample /usr/local/pgsql/data/recovery.conf

　コピーしたrecovery.confファイルのパラメータを以下の通り編集します。

　今回はrestore_commandにscpコマンドを用います。なお、scpコマンドを用いる場合は、各サーバでOpenSSHによってpostgresユーザーが公開鍵認証接続が可能となっている状態にしておく必要があります。NFSを用いて稼働系サーバのアーカイブログディレクトリを共有する場合は、cpコマンドでも問題ありません。

　primary_conninfoには、待機系サーバがトランザクションログを受け取る相手をhostで指定します。ここではnode1サーバとなります。また、userとpasswordにレプリケーション専用ユーザーであるrepliを指定します。

　これでnode2サーバの設定は完了です。

　node2サーバを起動します。

[postgres@node2 ~]$ pg_ctl start
server starting

カスケード接続されるnode3サーバの設定

　さらに、カスケード接続されるnode3サーバの設定を行います。手順はnode2サーバと同様です。

　まず、node2サーバのベースバックアップを取得します。

[postgres@node3 ~]$ pg_basebackup -D /usr/local/pgsql/data --xlog --verbose -h node2 -U repli
Password: # repli ユーザのパスワードを入力。今回はrepli。
transaction log start point: 0/3000020
transaction log end point: 0/4000000
pg_basebackup: base backup completed

　-hオプションでnode2サーバを指定します。

　recovery.confファイルの設定を行います。PostgreSQLのインストールディレクトリ下の"share/recovery.conf.sample"をデータベースクラスタディレクトリにコピーします。

[postgres@node3 ~]$ cp /usr/local/pgsql/share/recovery.conf.sample /usr/local/pgsql/data/recovery.conf

　コピーしたrecovery.confファイルのパラメータを以下の通り編集します。

　データを受け取るのはnode1サーバでなく、node2サーバであることに注意してください。primary_conninfoのhostはnode2を指定します。また、カスケードレプリケーションでは、restore_commandを設定する必要はありません。ストリーミングレプリケーション機能を通して、トランザクションログとアーカイブログの情報を取得できます。

　node3サーバを起動します。

[postgres@node3 ~]$ pg_ctl start
server starting

　これでレプリケーションの構築は完了しました。

レプリケーションの動作確認

　それでは、稼働系サーバでテーブルを作成してデータを投入し、待機系サーバにそれが反映されるか確認してみましょう。

　node1サーバのDBに接続してテーブルを作成してデータを投入します。

[postgres@node1 ~]$ psql -d postgres -U postgres
psql (9.2.4)
Type "help" for help.
postgres=# CREATE TABLE repli_test(id INT, comment TEXT);
CREATE TABLE
postgres=# INSERT INTO repli_test VALUES (1, 'test');
INSERT 0 1
postgres=# SELECT * FROM repli_test ;
 id | comment 
----+---------
  1 | test
(1 row)

　node2サーバ、node3サーバにもデータが反映されているか確認します。psqlコマンドは -c オプションでSQL文を1つ指定することができます。

[postgres@node2 ~]$ psql -c "SELECT * FROM repli_test" -d postgres -U postgres
 id | comment 
----+---------
  1 | test
(1 row)
[postgres@node3 ~]$ psql -c "SELECT * FROM repli_test" -d postgres -U postgres
 id | comment 
----+---------
  1 | test
(1 row)

　稼働系サーバのnode1サーバを停止して、待機系サーバのnode2サーバを稼働系サーバに昇格してみましょう。稼働系サーバの昇格はpg_ctl promoteを用います。

[postgres@node1 ~]$ pg_ctl stop
waiting for server to shut down.... done
server stopped
[postgres@node2 ~]$ pg_ctl promote
server promoting
[postgres@node2 ~]$ psql -c "UPDATE repli_test SET comment='promote test' WHERE id = 1"
UPDATE 1

　node2サーバを昇格させたので、データを変更できるようになったことが確認できます。

　ただし、カスケードスタンバイとして機能していたサーバ（今回はnode2サーバ）を昇格してしまうと、カスケードレプリケーションの接続が終了してしまう点に注意が必要です。node2サーバとnode3サーバ間のレプリケーションを再開したい場合は、もう一度ベースバックアップの取得からやり直す必要があります。

　ちなみに、PostgreSQL 9.3ではこの点が改良され、透過的にレプリケーション機能を利用できるようになる予定です。