Japan
サイト内の現在位置
PostgreSQL
PostgreSQL可用性向上の実現方法
PostgreSQLの可用性を向上するためには、サーバーに障害が発生した場合に業務に支障がでないよう、システムを冗長化した上で迅速な切り替えを行う必要があります。本ページでは、可用性向上を実現するいくつかの構成の概要と、負荷分散、切り替え、監視機能、難易度についてご紹介します。
本ページはPostgreSQLの可用性構成について検討する方を対象としています。
可用性実現の参考情報としてご活用ください。
ストリーミングレプリケーションの概要
ストリーミングレプリケーションとは、データベース全体を複製するクラスタ単位でのレプリケーションです。プライマリーサーバーで生成されたWALを、スタンバイサーバーに転送・適用することで更新情報を反映します。スタンバイサーバーでは参照のみが可能です。WALを転送・適用するタイミングは、設定により同期もしくは非同期を選択可能です。

フェイルオーバー
プライマリサーバー障害時にスタンバイサーバーを昇格させることで最小限のダウンタイムでの運用継続が可能です。
切り替え方法については、コマンドによる手動実行での切り替えが可能です。
また、切り替え後のレプリケーション再構築についてもコマンドによる手動実行が可能です。
ただし、ストリーミングレプリケーションのみの構成では自動でフェイルオーバーをすることはできません。

参照負荷分散
ホットスタンバイを有効にすると、スタンバイサーバーでも参照処理を実行することが可能となり、参照負荷の分散に活用することができます。参照負荷分散をすることで特定サーバーへの負荷が集中することを軽減できます。
ただし、ストリーミングレプリケーションのみの構成では自動で参照クエリを効率的に振り分けることはできません。

災害対策にストリーミングレプリケーションを活用
ストリーミングレプリケーションを使用し、遠隔地にスタンバイサーバーを構成することで災害対策に活用することができます。 災害時にはスタンバイサーバーに切り替えて業務を継続、再開することができます。
同期 |
・コミット完了までスタンバイからの応答を待つため、プライマリーの更新性能がやや下がる |
---|---|
非同期 |
・スタンバイからの応答を待たずにコミット完了するため、プライマリーの更新性能への影響が小さい |

CLUSTERPROの概要
CLUSTERPROはシステムの障害を監視し、障害発生時には健全なサーバーに業務を引き継ぎ、高可用性を実現するNECが製造販売するHAクラスタリングソフトウェアです。サーバー業務が続行できる状態であるかどうか、業務アプリケーション/サービスの視点を含め、広範囲に監視します。クラスタ化していることで、障害に対応するだけでなく、保守を行う場合にも有効です。
下記ガイドではPostgreSQLとCLUSTERPROを使用した環境の構築手順や設定例をご紹介しています。詳細につきましては、ガイドをご参照ください。
CLUSTERPRO X ソフトウェア構築ガイド

CLUSTERPRO+ストリーミングレプリケーションの概要
CLUSTERPRO+ストリーミングレプリケーションはこれらを組み合わせた高信頼・高可用なシステムを実現できます。PostgreSQLはレプリケーションを使用しており、プライマリーサーバー・スタンバイサーバーの2台のPostgreSQLサーバーをCLUSTERPROにてクラスタリングしています。

CLUSTERPROの監視、復旧動作で自動切替が可能
CLUSTERPROの各種モニタを使用すると、PostgreSQLのプロセス・スレッド、OS、ディスクなどの監視を行うことができます。また、サービスの復旧動作をスクリプトを作成し設定することで障害検出時には、プロセス再起動やフェイルオーバーなどを自動的に実行します。これにより、障害を極小化し、障害発生時の業務停止時間が短縮できます。

モニタ名 | 役割 |
---|---|
プロセス名モニタ |
PostgreSQLプロセスを監視して、その死活を検出します。 |
ディスクモニタ |
DB領域が格納されているディスクデバイス上で指定サイズのREADができることを監視します。 |
ユーザ空間モニタ |
ユーザ空間とカーネル間で通信を行っており、これが一定期間滞った場合にOS(Linux)をリセットします。 |
FIPモニタ |
フローティングIPアドレスが活性しているNICのLink Up/Downを監視します。NICのLink Downを検出すると異常と判断します。 |

Pgpool-II+ストリーミングレプリケーションの概要
Pgpool-IIとはPostgreSQLに対して、高可用性や負荷分散を可能にするための機能を提供する周辺OSSです。
ストリーミングレプリケーションのみの構成では実現できなかった自動フェイルオーバーや参照クエリの振り分けをPgpool-IIを使用することで実現できます。
詳しくはPgpool-Ⅱ機能紹介ご参照ください。

構成ごとのメリット・デメリット
PostgreSQL可用性について各構成のメリット、デメリットは以下の通りです。
構成:ストリーミングレプリケーション
メリット
・切り替え:コマンドが用意されており手動で可能
CLUSTERPROによるコールドスタンバイでのフェイルオーバーより、切り替え時間は短い
・難易度:PostgreSQLの設定変更後コマンドのみで簡単に構成可能
デメリット
・監視機能:監視機能がない
・負荷分散:クエリやサーバー負荷を考慮した負荷分散はできない
構成:CLUSTERPRO
メリット
・監視機能:CLUSTERPROの各種モニタを使用してリソース監視が可能
・切り替え:CLUSTERPROで復旧動作を設定することで自動フェイルオーバーが可能
・難易度:サーバーで共有ディスクの設定などが必要だが基本的にWebUIから簡単に設定が可能
CLUSTERPROのダッシュボード画面でクラスタの警告や異常を確認することが可能
デメリット
・負荷分散:負荷分散できない
・切り替え:ストリーミングレプリケーションよりも切り替え時間自体は長い
構成:CLUSTERPRO+ストリーミングレプリケーション
メリット
・監視機能:CLUSTERPROの各種モニタを使用してリソース監視が可能
・切り替え:CLUSTERPROで復旧動作を設定することで自動フェイルオーバーが可能
CLUSTERPROによるコールドスタンバイでのフェイルオーバーより、切り替え時間は短い
・難易度:CLUSTERPROのダッシュボード画面でクラスタの警告や異常を確認することが可能
デメリット
・負荷分散:クエリやサーバー負荷を考慮した負荷分散はできない
・難易度:それぞれの設定に加えて、CLUSTERPROで自動フェイルオーバーの設定が必要である
復旧動作の設定としてスクリプトの作成が必要になる
構成:Pgpool-Ⅱ+ストリーミングレプリケーション
メリット
・負荷分散:参照クエリを複数のサーバーへ効率的に振り分けることが可能
・切り替え:自動でフェイルオーバー可能
CLUSTERPROによるコールドスタンバイでのフェイルオーバーより、切り替え時間は短い
・監視機能:Watchdogを使用してサーバー同士で互いに監視が可能
※Pgpool-IIを複数台構築する場合の相互監視
デメリット
・難易度:データベースのプライマリーサーバーとスタンバイサーバーに加えて、
Pgpool-II用のサーバーを用意して設定する必要がある
お問い合わせ