SRA OSS, Inc. 日本支社
pgpool 3.1.1についてインストール・設定の容易性や機能の有効性、PostgreSQLからの移行性、耐障害性といった観点から運用性を評価した。 また、評価では、テストデータやトランザクションの作成にはpgbenchを、レプリケーションの確認には今回開発したコンペアツールを使用した。
| H/W | 自作 |
|---|---|
| CPU | Intel Pentium 4 HT ON |
| メインメモリ | 1GB |
| HDD | 80GB |
| OS | CentOS 4.2 |
| 評価対象ソフトウェア | pgpool 3.1.1 |
| 負荷ツール | pgbench 8.1.5 |
| H/W | 自作 |
|---|---|
| CPU | Intel Pentium 4 HT ON |
| メインメモリ | 1GB |
| HDD | 80GB |
| OS | CentOS 4.2 |
| 評価対象ソフトウェア | PostgreSQL 8.1.5 |
| 負荷ツール | pgbench 8.1.5 |
| H/W | 自作 |
|---|---|
| CPU | Intel Pentium 4 HT ON |
| メインメモリ | 1GB |
| HDD | 80GB |
| OS | CentOS 4.2 |
| 評価対象ソフトウェア | PostgreSQL 8.1.5 |
| 負荷ツール | pgbench 8.1.5 |
評価は以下の観点を中心に実施した。 また、評価ではインストール・設定手順、障害復旧手順をまとめた。
ソフトウェアのインストール、設定が容易であるかということは個人の知識と技術に依存するところが大きい。 ここでは、pgpool 3.1.1のインストール・設定が一般的なLinuxのソフトウェアと比較して容易であるかということについて評価した。 pgpool 3.1.1のインストール・設定の容易性に関する評価結果は表1に示すとおりである。 なお、インストール・設定手順については「pgbenchによるpgpool 3.1.1の運用性に関する評価手順」を参照されたい。
| 容易性 | 備考 | |
|---|---|---|
| インストール | ○ | ソースコードからインストールする場合には一般的なLinuxのソフトウェアと同様に./configure、make、make installという手順によってインストールすることが可能である。 また、RPMパッケージも提供されており、一部のディストリビューション(Debian GNU/LinuxやFedora Coreなど)では公式にパッケージが配布されている。 |
| 設定 | ○ | pgpoolに関する設定は基本的にpgpool.confファイルに集約されており、pgpool.confファイルの書式はpostgresql.confファイルを踏襲している。 従って、PostgreSQLを使用しているユーザであれば比較的容易に設定することが可能である。 |
pgpool 3.1.1が備える機能の有効性について評価した。 pgpool 3.1.1の機能の有効性に関する評価結果は表2に示すとおりである。
| 機能 | 有効性 | 備考 |
|---|---|---|
| コネクションプール | ○ | 図1に示すように、pgpoolを使用しない場合と比較してINSERT、UPDATEコマンドを含むトランザクション(mixed)ではおよそ260%、SELECTコマンドのみ(SELECT only)ではおよそ440%の処理性能が向上することを確認できた。 |
| レプリケーション | ○ | コンペアツールを用いて、マスタとセカンダリに同じデータが格納されることを確認できた。 |
| ロードバランス | ○ | 図2に示すように、pgpool.confファイルで指定した重み付けに従ってトランザクションがプライマリとセカンダリに振り分けられることを確認できた。 |
| 障害検知 | ○ | ネットワーク障害やサーバ障害を検知し、コネクションプールモードではセカンダリにフェイルオーバし、レプリケーションモードでは障害の発生したノードを切り離して縮退運転に移行することを確認できた。 データ不整合の検知については、データを検索した結果の行数が異なる場合や、マスタとセカンダリのいずれかにおいてクエリーの実行に失敗した場合のみ、エラーとなることを確認できた。 |
| フェイルオーバ | ○ | セカンダリにフェイルオーバし、サービスが継続されることを確認できた。 |
| 縮退運転 | ○ | 障害の発生したノードを切り離して縮退運転に移行し、サービスが継続されることを確認できた。ただし、障害発生時のセッションは継続されない。 |

図1: pgpoolのコネクションプール機能によるトランザクションの処理性能

図2: pgpoolのロードバランス機能によるトランザクションの振り分け
PostgreSQLを使用したクライアントアプリケーションをpgpoolのレプリケーションモードを使用した構成に移行する際に、クライアントアプリケーションが実行するSQLを修正せずに移行できるかということについて評価した。 pgpoolのPostgreSQLからの移行性に関する評価結果は表3に示すとおりである。 なお、SQLを移行できるかということはマスタとセカンダリ間のデータを一致させることができることをもって判断した。
| SQL | 移行性 | 備考 |
|---|---|---|
| データ定義コマンド(DDL) | ○ | テーブルの作成や変更、削除などのデータ定義コマンドを使用したSQLは修正せずに移行できる。 |
| オブジェクト識別子(OID) | △ | マスタとセカンダリ間でOIDが一致していれば、OIDを使用したSQLは修正せずに移行できる。 ただし、データ定義コマンドやラージオブジェクトのインポートを実行する際には、データベースクラスタ内で複数のデータベースによって共有されるシステムカタログのロックを取得する必要がある。 |
| トランザクションID | × | マスタとセカンダリ間でトランザクションIDが一致せず、トランザクションIDを使用したSQLは移行できない。 |
| 連番型(serial、bigserialデータ型) | ○ | pgpool.confファイルでinsert_lockパラメータを有効に設定すれば、連番型の列が定義されたテーブルへのINSERTコマンドは修正せずに移行できる。コンペアツールを用いることで、ほぼ同時に多くのINSERTコマンドを実行しても連番にずれが出ないことを確認できた。 |
| 乱数値(random関数) | △ | クライアントアプリケーションで乱数値を生成し、それをSQLに埋め込んで実行すれば、乱数値を使用したSQLは移行できる。 |
| 現在の日付と時刻(current_timestamp関数など) | △ | クライアントアプリケーションで現在の日付と時刻を取得し、それをSQLに埋め込んで実行すれば、現在の日付と時刻を使用したSQLは移行できる。 |
| シーケンス | ○/△ | pgpool.confファイルでinsert_lockパラメータを有効に設定すれば、シーケンスを使用したINSERTコマンドは修正せずに移行できる。 ただし、INSERTコマンド以外についてはSQLの先頭に/*INSERT LOCK*/というコメントを付加するか、LOCK TABLEコマンドによって明示的にテーブルのロックを取得する必要がある。 コンペアツールを用いることで、ほぼ同時に多くのINSERTコマンドを実行してもシーケンス値にずれが出ないことを確認できた。 |
| ラージオブジェクト | △ | マスタとセカンダリ間でOIDが一致していれば、ラージオブジェクトを使用したSQLは修正せずに移行できる。 ただし、ラージオブジェクトをインポートする際にはデータベースクラスタ内で複数のデータベースによって共有されるシステムカタログのロックを取得する必要がある。 |
pgpoolを使用したシステムに障害が発生した際の耐障害性について、データベースとしてのサービスを継続できるかという観点をもとに評価した。 pgpoolの耐障害性に関する評価結果は表4に示すとおりである。
| 障害 | 耐障害性 | 備考 |
|---|---|---|
| pgpoolプロセス障害 | × | サービスが停止する。 |
| ネットワーク障害 | ○ | コネクションプールモードではセカンダリにフェイルオーバし、レプリケーションモードでは障害の発生したノードを切り離して縮退運転に移行し、サービスを継続する。 |
| DBサーバ障害 | ○ | コネクションプールモードではセカンダリにフェイルオーバし、レプリケーションモードでは障害の発生したノードを切り離して縮退運転に移行し、サービスを継続する。 |
| データ不整合 | ○ | データを検索した結果の行数が異なる場合や、マスタとセカンダリのいずれかにおいてクエリーの実行に失敗した場合にエラーとなるが、サービスを継続する。 |
| 障害復旧 | △ | 障害復旧にはpgpoolを停止する必要があり、サービスが停止する。障害復旧後はコンペアツールを用いて、マスタとセカンダリに同じデータが格納されていることを確認できた。 なお、復旧手順については「pgbenchによるpgpool 3.1の運用性に関する評価手順」を参照されたい。 |