pgbenchによるSlony-I 1.2.1の運用性に関する評価結果 || OSS iPedia

pgbenchによるSlony-I 1.2.1の運用性に関する評価結果

SRA OSS, Inc. 日本支社

Slony-I 1.2.1についてインストール・設定の容易性や機能の有効性、PostgreSQLからの移行性、耐障害性といった観点から運用性を評価した。また、評価では、テストデータやトランザクションの作成にはpgbenchを、レプリケーションの確認には今回開発したコンペアツールを使用した。

1.評価環境

H/W	自作
CPU	Intel Pentium 4 HT ON
メインメモリ	1GB
HDD	80GB
OS	CentOS 4.2
評価対象ソフトウェア	Slony-I 1.2.1 PostgreSQL 8.1.5
負荷ツール	pgbench 8.1.5

H/W	自作
CPU	Intel Pentium 4 HT ON
メインメモリ	1GB
HDD	80GB
OS	CentOS 4.2
評価対象ソフトウェア	Slony-I 1.2.1 PostgreSQL 8.1.5
負荷ツール	pgbench 8.1.5

H/W	自作
CPU	Intel Pentium 4 HT ON
メインメモリ	1GB
HDD	80GB
OS	CentOS 4.2
評価対象ソフトウェア	Slony-I 1.2.1 PostgreSQL 8.1.5
負荷ツール	pgbench 8.1.5

2.評価ポイント

評価は以下の観点を中心に実施した。また、評価ではインストール・設定手順、障害復旧手順をまとめた。

インストール・設定の容易性
機能の有効性
PostgreSQLからの移行性
耐障害性

3.評価手順

pgbenchによるSlony-I 1.2.1の運用性に関する評価手順

4.評価結果

4.1.インストール・設定の容易性

ソフトウェアのインストール、設定が容易であるかということは個人の知識と技術に依存するところが大きい。ここでは、Slony-I 1.2.1のインストール・設定が一般的なLinuxのソフトウェアと比較して容易であるかということについて評価した。Slony-I 1.2.1のインストール・設定の容易性に関する評価結果は表1に示すとおりである。なお、インストール・設定手順については「pgbenchによるSlony-I 1.2.1の運用性に関する評価手順」を参照されたい。

表1: Slony-I 1.2.1のインストール・設定の容易性に関する評価結果(○: 容易である。×: 容易でない。)
	容易性	備考
インストール	○	ソースコードからインストールする場合には一般的なLinuxのソフトウェアと同様に./configure、make all、make installという手順によってインストールすることが可能である。また、RPMパッケージでも提供されている。
設定	×	Slony-I 1.2.1のデーモンであるslonプロセスに関する設定は、slonikという独特なツールを用いて行うため、慣れるまでに多少時間を要する。また、レプリケーションはテーブル単位で行えるため柔軟な構成が可能な反面、その分設定項目が多く、導入はpgpoolと比較すると容易ではない。

4.2.機能の有効性

Slony-I 1.2.1が備える機能の有効性について評価した。 Slony-I 1.2.1の機能の有効性に関する評価結果は表2に示すとおりである。

表2: Slony-I 1.2.1の機能の有効性に関する評価結果(○: 有効である。×: 有効でない。)
機能	有効性	備考
レプリケーション	○	コンペアツールを用いて、マスタとスレーブに同じデータが格納されることを確認できた。
カスケード接続	○	スレーブをカスケード接続し、コンペアツールを用いてマスタと２台のスレーブに同じデータが格納されることを確認できた。
障害検知	○	slonプロセスの障害を検知して、自動的にslonプロセスを再起動するウォッチドッグスクリプトが用意されている。DBサーバ障害やネットワーク障害を検知する機能はないが、Slony-Iを使用したシステムの構成ではフェイルオーバやスイッチオーバに人の判断が必要となるため、存在してもあまり意味がない。
スイッチオーバ	○	slonikツールのMOVE SETコマンドを使用して、手動でマスタの役割を他のノードに移行できることが確認できた。ただし、この処理はクライアントがデータベースに再接続することを必要とする。
フェイルオーバ	○	slonikツールのFAILOVERコマンドを使用して、手動でマスタの役割を他のノードに移行できることが確認できた。ただし、この処理もスイッチオーバ時と同様にクライアントがデータベースに再接続することを必要とする。スイッチオーバとの違いは、マスタが壊れたことを前提としていることである。

4.3.PostgreSQLからの移行性

PostgreSQLを使用したクライアントアプリケーションをSlony-Iのレプリケーション機能を使用した構成に移行する際に、クライアントアプリケーションが実行するSQLを修正せずに移行できるかということについて評価した。 Slony-IのPostgreSQLからの移行性に関する評価結果は表3に示すとおりである。なお、SQLを移行できるかということはマスタとスレーブ間のデータを一致させることができることをもって判断した。

表3: Slony-IのPostgreSQLからの移行性に関する評価結果(○: 修正せずに移行できる。×: 移行できない。△: 修正すれば移行できる。)
SQL	移行性	備考
データ定義コマンド(DDL)	△	テーブルの作成や変更、削除などのデータ定義コマンドを使用したSQLは基本的には移行できない。ただし、それらのSQLをスクリプトとして用意し、それをslonikツールのEXECUTE SCRIPTコマンドに渡して実行するようにすれば移行できる。
オブジェクト識別子(OID)	×	マスタとスレーブ間でOIDが一致せず、OIDを使用したSQLは移行できない。
トランザクションID	×	マスタとスレーブ間でトランザクションIDが一致せず、トランザクションIDを使用したSQLは移行できない。
連番型(serial、bigserialデータ型)	○	連番型の列が定義されたテーブルへのINSERTコマンドは修正せずに移行できる。コンペアツールを用いることで、ほぼ同時に多くのINSERTコマンドを実行しても連番にずれが出ないことを確認できた。
乱数値(random関数)	○	乱数値を使用したSQLは修正せずに移行できる。
現在の日付と時刻(current_timestamp関数など)	○	現在の日付と時刻を使用したSQLは修正せずに移行できる。
シーケンス	○	シーケンスを使用したSQLは修正せずに移行できる。コンペアツールを用いることで、ほぼ同時に多くのINSERTコマンドを実行してもシーケンス値にずれが出ないことを確認できた。
ラージオブジェクト	×	Slony-IはPostgreSQLのトリガを利用してレプリケーションを行うが、ラージオブジェクト操作をした場合には適切なトリガを起動できないため、ラージオブジェクトを操作するSQLは移行できない。

4.4.耐障害性

Slony-Iを使用したシステムに障害が発生した際の耐障害性についてデータベースとしてのサービスを継続できるかという観点をもとに評価した。 Slony-Iの耐障害性に関する評価結果は表4に示すとおりである。

表4: Slony-Iの耐障害性に関する評価結果(○: サービスが継続できる。×: サービスが停止する。△: 場合によりサービスが継続できる。)
障害	耐障害性	備考
slonプロセス障害	○	マスタ側、スレーブ側のどちらか、もしくは両方のslonプロセスが停止した場合、レプリケーションは行われなくなるが、サービスを継続する。
ネットワーク障害	×(マスタ)/△(スレーブ)	マスタ側のDBサーバにネットワーク障害が起きた場合、マスタ側のDBサーバの操作が不可能になる。一方、スレーブ側のDBサーバにネットワーク障害が起きた場合はスレーブ側のDBサーバの操作が不可能になる。ただし、スレーブ側をバックアップの目的で使用している場合は、マスタ側でサービスを継続する。
DBサーバ障害	×(マスタ)/△(スレーブ)	マスタ側でDBサーバ障害が起きた場合、マスタ側のDBサーバの操作が不可能になる。一方、スレーブ側でDBサーバ障害が起きた場合はスレーブ側のDBサーバの操作が不可能になる。ただし、スレーブ側をバックアップの目的で使用している場合は、マスタ側でサービスを継続する。
データ不整合	○	Slony-Iの導入後は、直接スレーブに接続してデータを更新することができない状態になっている。従って、誤操作によりマスタとスレーブ間でテーブルが不整合の状態になり、サービスが停止する可能性は低い。
障害復旧	○	障害後も停止せずにレプリケーションを再開することができる。障害復旧後はコンペアツールを用いて、マスタとスレーブに同じデータが格納されていることを確認できた。なお、復旧手順については「pgbenchによるSlony-I 1.2.1の運用性に関する評価手順」を参照されたい。

OSS iPedia