安心のデータ管理を実現するデータベース冗長化

4.2. コスト重視のレプリケーション適用事例 |

4.3. 可用性重視のレプリケーション適用事例

ここでは、PostgreSQLで同期方式を実現する機能を持つツールpgpool-IIを使い、高い可用性を持つレプリケーションを実現した事例を紹介します。

本事例と前節の事例とで大きく異なる点は、「商用サービスのためシステムを止められない」という点です。
そこで、障害の発生時に停止せずに自動で縮退運用へ切り換える機能、すなわち同期方式を実現するpgpool-IIを使った構成を選択しました。

pgpool-IIは、PostgreSQLとは別プロセスで稼働し、クライアントとPostgreSQLとの間でproxyの役目を果たします。クライアントは常にpgpool-IIに接続すればよく、pgpool-IIの先の構成を知る必要はありません。
pgpool-IIはクライアントからの更新要求を受け付けると、マスタにその依頼を転送します。マスタの更新が終わると、すべてのスレーブに同じ更新依頼を転送します。すべての更新処理が終わったら、クライアントに応答を返します。

通常運用時も縮退運用時も、利用者はpgpoolに接続します。pgpoolは障害の有無を判別して適切にマスタまたはスレーブに接続します。

図4-2 pgpool-Ⅱ適用事例の図

pgpool-IIは、同期方式の実現だけでなく、レプリケーションを構成するデータベースの状態を定期的に監視する機能も持っています。クライアントがデータベースを利用していない時間帯でも、この定期監視にて障害をいち早く検知することが可能です。


障害発生時の対処

この事例構成においては、マスタで障害が発生した場合の 縮退構成への移行はpgpool-IIが自動的に行います。pgpool-IIはマスタ障害を検知したら自動的にマスタを切り離し、いずれかのスレーブ1つを代替マスタに昇格させて運用を継続します。

非同期方式の場合のように運用を停止する必要はなく、クライアントからの接続変更も不要です。スレーブが先にダウンした場合もやはり自動で、スレーブを切り離したのちマスタのみの縮退運用に移行します。

また、pgpool-IIでは、障害を検知した際に、任意のプログラム実行を行わせることが可能です。その際には、どのデータベースで障害が起きたか、マスタ代替が行われたかどうか等の情報を取得できるため、ログ出力やメール送信などを組み込むことで、障害発生を迅速に把握できるような機能を実現できます。この事例では、syslogに情報を出力し、syslog転送機能にて外部の監視機構へ通知する方法を採りました。

縮退構成から通常構成への復旧には、以下のような作業を実施することになります。

  1. マスタを復旧します。
  2. 縮退運用中のマスタ(=通常構成時のスレーブ)に加えられた更新を、本来のマスタへ反映します。
  3. pgpool-IIにマスタ復旧を伝達します。これにより、自動的に 通常運用構成に戻ります。

復旧作業中は、前節のコストを重視した事例同様、運用を停止する必要があります。ただし、クライアント側には接続設定変更等の対処は不要となります。


本事例構成のまとめ

本事例構成は、pgpool-IIをプロセス稼働させる必要があり、前節のコストを重視した事例に比べると、サーバリソース面で初期コスト/運用コストが高くなります。
しかしpgpool-IIを導入することで、データベースの死活監視、障害検知、及び、縮退構成への自動移行を行えるようになり、障害が発生した場合でも停止しないシステムを実現できました。

障害を検知した際の通知機構については外的な対応が必要ですが、OS上のコマンド形式で組み込めるため、柔軟に対応できます(この事例の場合、前述のsyslog転送)。

ただしクライアントからのアクセスをpgpool-IIが一手に担うため、pgpool-II自体がダウンすると運用が停止してしまいます。このため、この事例のような構成では、pgpool-IIの死活監視が必須となります。
本事例では、外部の監視機構に依頼しましたが、そのような監視機構がない場合は独自に組み込む必要があります。
システムの安定稼働を確保するうえでは、pgpool-II自体の冗長化も視野に入れる必要があるでしょう。

クライアントプログラム開発においては、少し留意する必要がありました。
pgpool-IIが障害を検知するタイミングは、クライアントからのアクセス、及び、定期監視のいずれかとなります。定期監視で障害を検知し縮退移行した場合は、その後のクライアントアクセスは正常に行えるのですが、クライアントからのアクセスで障害を検知した場合は、一度 データベースエラーが返されます。その場合は再実行で正常処理できるため、クライアントプログラムには処理のリトライを組み込みました。
この点以外は、直接PostgreSQLにアクセスするプログラムと差異はありません。

無料小冊子のお申込みはこちら

株式会社システム計画研究所のオフィシャルサイトはこちら

当サイトへのご質問及び安全・安心・信頼のシステム開発に関するご相談はこちら

通信・ネットワークシステムの開発マネージメント情報サイト「通信・ネットワークシステム開発.COM」はこちら

サーバ監視・ネットワーク監視ツール isNetSentry-S のサイトはこちら