PowerGres V9.1 のストリーミングレプリケーション機能には、同期と非同期の２つのレプリケーション方式があります。どちらの方式が良いかを迷う方も多いかと思います。下記表は、２つのレプリケーション方式に、レプリケーションなしの単独構成を加え、各構成の特性を一覧にしたものとなります。構成を検討する際の参考として下さい。
※評価基準は○、△、×の相対的な三段階評価で、- は評価対象外の項目となります。

上表の通り、どの構成も一長一短と言えます。しかしながら実際には、データベースという性格上、信頼性が重視されレプリケーション構成が好まれているようです。

では、同期と非同期の違いはどうでしょうか。サービス継続性(待機系障害時)が最も評価に差がある項目となっています。
この項目は、待機系サーバがダウンした場合にサービスが停止するかを基準に評価した項目になります。

同期レプリケーションでは、データ更新があった場合、待機系サーバの同期が完了するまで待ち、同期の完了は待機サーバの応答によって判断します。そのため、待機系サーバから応答がなくなった場合、稼働系サーバは応答を待ち続けてしまい、データ更新が行えない状態になります。

同期レプリケーション方式では、そのような状態に陥らないよう、複数の待機系サーバを用意しておくのが一般的となります。なお、非同期レプリケーションでは、待機系サーバの応答を待ちません。非同期レプリケーションは、複数の待機系サーバを用意する必要がないという点に関して、有利と言えます。

ここからはレプリケーションの設定方法について紹介していきます。なお、本記事の前提条件として、ホットスタンバイ/ストリーミングレプリケーションの構築は完了していることとします。まだ済んでいない場合は、第 2 回 ホットスタンバイ/ストリーミングレプリケーションを構築してみよう を参考に環境を用意して下さい。

レプリケーションの設定は稼動系でのみ行えます。待機系ではメインメニューに「レプリケーション」は表示されません。

各入力項目の説明については、以下をご覧下さい。

「レプリケーション」の「設定」タブより設定を行い、「適用」をクリックします。

適用が完了すると、ポップアップが表示されます。

指示に従って「サービス」の「設定を再読み込み」をクリックし、設定の再読み込みを行います。

これでレプリケーションの設定は完了となります。

前述した通り、同期レプリケーション方式は、待機系サーバがダウンして応答がなくなった場合、応答を待ち続けてしまい、データ更新が行えない状態になります。そのため、同期レプリケーション方式では、待機系サーバがダウンした場合でもデータ更新が行えるように、複数の待機系サーバを用意しておくのが一般的となります。(参照：1.同期・非同期レプリケーションの特性について)

しかしながら、更にもう一台のサーバを追加して調達することは、費用面を考えると容易ではありません。また、サーバ管理者にとって負担が増えることにもなります。そのため、同期レプリケーションは敷居が高いものと捉えられ、導入が見送られることも少なくありません。

PowerGres V9.1 では、このような問題の解消策として、同期・非同期レプリケーションの自動切り替え設定が用意されています。自動切り替え設定を有効にすると、待機系サーバから応答が返ってこなくなった場合、同期から非同期のレプリケーションに切り替えます。この振舞によって、待機系サーバから応答が返ってこなくなった場合もデータ更新が可能となります。
また、同期スタンバイとして動作する待機系サーバ状態の「監視間隔」を分刻みで設定することができます。

本章では、同期レプリケーションを設定した場合と、同期・非同期レプリケーション自動切り替えを設定した場合における待機系サーバ停止時の振舞を比較します。

まずは、同期レプリケーション方式で待機系サーバ停止時の振舞を確認します。
「レプリケーション」の「設定」タブより同期レプリケーション方式に設定し、「同期・非同期レプリケーションを自動的に切り換える」のチェックを外します。設定適用手順は、前述の 2.1.同期・非同期の切り替え を参照してください。

待機系のサービスを停止します。

待機系のサービスが停止されたことを確認します。

稼働系にて INSERT 文を実行し、どのような振舞になるかを確認してみます。
ここでは、psql コマンドラインツールより稼働系に接続し、データベース hotdb の t1 テーブルに対して INSERT 文を実行しています。データベース hotdb、t1 テーブルは第２回の記事にて作成しています。

データベース hotdb の t1 テーブルに対して INSERT 文を実行します。

上記の画面では分かりにくいですが、INSERT 文を実行すると、待機系から応答が返ってこないため、処理が完了しません(無応答状態)。Ctrl + c でキャンセルすると、以下のように待機系への同期が完了していない旨を表す WARNING メッセージが出力されます。

以上のように、同期レプリケーション方式で待機系がダウンした場合は、稼働系のサービスも事実上停止してしまうことになります。

では次に、同期・非同期レプリケーション自動切り替え方式で待機系サーバを停止した時の振舞を確認します。
先程、待機系のサービスを停止したので待機系のスタンバイを再開します。

「レプリケーション」の「設定」タブより「同期・非同期レプリケーションを自動的に切り換える」を設定します。また、「監視間隔」はデフォルトのまま 1分で設定します。設定適用手順は、前述の 2.1.同期・非同期の切り替え を参照してください。

先程と同様に、待機系のサービスを停止し、psql コマンドラインツールより稼働系に接続し、データベース hotdb の t1 テーブルに対して INSERT 文を実行します。

こちらの設定の場合は、INSERT 文を実行しても応答が返ってきます。

以上のように、同期・非同期レプリケーション自動切り替えを設定しておくと、待機系サーバから応答が返ってこなくなった場合にもデータ更新が可能となります。待機系サーバダウンによってサービス全体が提供不能となる事態を防ぐことができ、とても便利な機能と言えます。

PowerGres V9.1 ではレプリケーション状態の表示が一覧として表示され、レプリケーション状態が一目で確認できます。
※項目数が多いため、スクロール形式で表示されます。

右にスクロールすると以下のように表示されます。「同期状態」が「sync」の場合は同期、「async」の場合は非同期と表示され、自動切り替えを設定している場合は適宜状態が変更されます。

さて、第２回の記事からこれまで、レプリケーションに関する様々な設定を行ってきました。障害対策として構築してきた環境ですが、実際に障害が起こった場合の想定をしておかなければ、管理者としてスムーズな対応を行えません。

本章では構築した環境をもとに、障害発生時のシミュレーションを行います。
今回は稼働系サーバがダウンした場合を想定し、管理者が行うべき操作などを紹介します。
※本シミュレートは、同一マシンに稼働系、待機系ともに構築している背景から、PowerGres GUI 管理ツールより各サーバを停止することで、サーバ障害を模しています。その本質から PowerGres 管理者の操作ミスによってサーバを誤停止してしまった場合などの対処法としても流用できます。

本シミュレートの具体的な想定としては、稼働系のダウンによって、アプリケーションからのDBアクセスが受け付けられなくなり、システム全体に影響を及ぼしている(早急な復旧対応を行う必要がある)状況となります。

稼働系のダウンは、PowerGres GUI 管理ツールからサービスを停止することにより再現します。
その後、待機系を稼働系へ切り替える(フェイルオーバ)ことでサービスの復旧を行う段取りとなります。

では実際に見ていきましょう。まずは稼働系の「サービス」より「サービスを停止」をクリックし、擬似的に障害を発生させます。

稼働系のサービスが停止されていることを確認します。

待機系を稼働系に切り替え、サービスを復旧します。

待機系が稼働系に切り替わったことを確認します。

以上でフェイルオーバは完了となります。さて。これでサービスの復旧が行われたはずです。
psql で DB に接続できるかを確かめてみましょう。データベース hotdb に接続してみます。

ここでは、INSERT 文が正常に実行されるかを確認します。
当たり前ですが、本番サーバにおいて確認する場合は、運用中に使用されているテーブルに対して行うとデータが追加されてしまうので、更新系クエリの実行を確認する場合は、適当なテーブルを用意して下さい。

INSERT 文が正常に実行されたことが確認できたので、稼働系として動作していることが確認できました。

以上、稼働系のダウンを想定した簡単なシミュレートを行ってみました。非常に簡単な操作でサービスを復旧することができました。
PowerGres を利用すれば、障害発生時もスムーズに対応できます。また、今回は紹介できませんでしたが、pgpool-ha, Heartbeat/Pacemaker などのミドルウェアと PowerGres を組み合わせることによって、サーバ障害を自動検知し、自動でフェイルオーバを行う構成にすることもできます。手動フェイルオーバでは要件に合わない、というミッションクリティカルなシステムにおいても PowerGres は利用することができます。

今回は、レプリケーションの同期・非同期の切り替え設定、障害シミュレーションを紹介しました。障害発生に備えておくことで、障害の被害は最小限に抑えることができます。その備えの一つとして、PowerGres が皆さんのお役に立てればと思います。

さて、全３回に渡ってお届けした PowerGres V9.1 体験記ですが、今回で最終回となります。レプリケーション関連の話を中心に紹介致しましたが、ご理解いただけたでしょうか。皆さんが本記事を通して PowerGres および PostgreSQL の最新機能に少しでも興味を持って頂けたら幸いです。