今回は図のように、PGClusterのレプリケーションサーバを2台のホスト上で稼働させて冗長化構成にしてみよう。

通常はPC2上のpgreplicateがレプリケーションサーバとして働く。万一PC2に障害が発生した場合、PC3上のpgreplicateに処理が切り替わり、レプリケーションシステム全体は停止することなく動き続ける……というのが今回のシナリオである。

まず、新しいホストにPGClusterを導入し、レプリケーションサーバを設定する。pgreplicate.confの設定は、基本的に既存のレプリケーションサーバと同一でよい。各クラスタサーバとロードバランサの情報を記述しよう。また、レプリケーションサーバのカスケード接続に関する設定項目も、pgreplicate.confのサンプルには用意されている。この機能はバージョン1.0.7では未実装だが、レプリケーションサーバを複数用意する場合の待機系設定として使えるとのことなので、今回は以下のように記述してみた。

次に既存のレプリケーションシステムの設定を変更する。各クラスタサーバの設定ファイル「cluster.conf」に<Replicate_Server_Info>の設定を追加し、新しく導入したレプリケーションサーバの情報を記述する。

設定は以上。クラスタサーバ2台、レプリケーションサーバ2台、ロードバランサ1台の計5台を順次起動して、レプリケーションシステムを開始する。

では、実際にレプリケーションサーバに障害が起きた場合をシミュレーションしてみよう。テストは以下の手順で行った。

1. ロードバランサに接続して、INSERTやDELETEなどの更新系クエリを実行。
2. 各データベースクラスタに接続し、更新結果が反映されているか確認。
3. PC2上のレプリケーションサーバを停止。
4. 再びロードバランサに接続し、INSERTやDELETEなどの更新系クエリを実行。
5. 再び各データベースクラスタに接続し、更新結果が反映されているか確認。

結果から言うと、全て問題なく動作した。PC2上のレプリケーションサーバが停止しても、すぐに待機系のPC3が引き継いでレプリケーションシステム全体は止まることなく動き続ける。PC3が稼働している間にPC2を復旧してレプリケーションサーバを再起動すれば、今度はPC2が自動的に待機系となる。さらに、PC3のレプリケーションサーバも停止してみたところ、更新系のクエリは"This query is not permitted when all replication servers fell down"というワーニングが出力されて実行できなくなった。つまり、各クラスタはread_onlyモードに切り替わったわけだ。

なお、今回のテストではレプリケーションサーバがうまく待機系に切り替わらず一晩悩んでしまったが、どうやら各サーバ間で時計が同期できていなかったためらしい。大いに反省。