お問い合わせ
03-5979-2701
PowerGres
PowerGres 体験記 戻る

第3回 レプリケーションの同期・非同期の切り替えをしてみよう

対象バージョン: PowerGres V9.1
本文では Microsoft Windows 7 (64 ビット版) において PowerGres on Windows V9.1 Update1 を使用して解説しています。

第2回の記事にて、 ホットスタンバイ/ストリーミングレプリケーション(非同期)構成を構築しました。V9.1 では、同期レプリケーションに対応し、待機系に未反映のデータが失われるという制限事項がなくなりました。また、PowerGres V9.1 では独自機能として、同期・非同期の自動切り替え機能が備わっています。今回は、第2回の記事にて構築した環境に対してレプリケーションの同期・非同期の切り替え設定を行い、障害発生時を模したシミュレーションを紹介します。

  1. 同期・非同期レプリケーションの特性について
  2. レプリケーションの設定
    1. 同期・非同期の切り替え
      1. 同期・非同期の自動切替
    2. レプリケーション状態の表示
  3. 障害発生時のシミュレーション
    1. シミュレート
  4. まとめ

同期・非同期レプリケーションの特性について

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

各構成の特性
方式サービス継続性
(稼働系障害時)
サービス継続性
(待機系障害時)
負荷分散更新性能管理性
同期××
非同期
レプリケーションなし×-×

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

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

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

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

レプリケーションの設定

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

同期・非同期の切り替え

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

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

レプリケーションの設定
設定項目設定値設定項目の説明
非同期・同期方式の設定同期レプリケーションレプリケーション方式を選択します
同期コミットonトランザクションのコミットを同期で行うかどうかを指定します
同期スタンバイ名standby同期スタンバイとして動作する待機系サーバのアプリケーション名を指定します。アプリケーション名はサーバの登録時に指定したラベルとなります
同期・非同期レプリケーションの自動切り換えの設定チェックする詳細は後述します
監視間隔1詳細は後述します

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

図: レプリケーション設定画面1

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

図: レプリケーション設定画面2

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

図: レプリケーション設定画面3

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

同期・非同期の自動切替

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

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

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

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

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

図: 自動切り替え方式の振舞確認1

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

図: 自動切り替え方式の振舞確認2

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

図: 自動切り替え方式の振舞確認3

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

図: 自動切り替え方式の振舞確認4

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

図: 自動切り替え方式の振舞確認5
図: 自動切り替え方式の振舞確認6

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

図: 自動切り替え方式の振舞確認7

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

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

図: 自動切り替え方式の振舞確認8

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

図: 自動切り替え方式の振舞確認9

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

図: 自動切り替え方式の振舞確認10
図: 自動切り替え方式の振舞確認11
図: 自動切り替え方式の振舞確認12

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

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

レプリケーション状態の表示

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

図: レプリケーション状態の表示画面1

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

図: レプリケーション状態の表示画面2

障害発生時のシミュレーション

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

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

シミュレート

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

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

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

図: シミュレート画面1

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

図: シミュレート画面2

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

図: シミュレート画面3

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

図: シミュレート画面4

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

図: シミュレート画面5
図: シミュレート画面6

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

図: シミュレート画面7
図: シミュレート画面8

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

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

まとめ

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

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