OSS iPedia

考察詳細

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

インストールは、一般的なLinuxのソフトウェアと同様に行うことが可能である。ただし、設定はslonikという独特なツールを用いて行うため、慣れるまでに多少時間を要する。また、レプリケーションはテーブル単位で行えるため、柔軟な構成が可能な反面、その分設定項目が多く、導入はpgpoolと比較すると容易ではない。ただし、ドキュメントは丁寧に書かれており、それを一通り読めばおおよそ問題なく導入できる。

Slony-Iでは、ロードバランス機能が提供されておらず、複数のノードに対してデータの検索を振り分けたり、データの更新をマスタのみに送信したりするには、基本的にクライアントアプリケーションで対応する必要がある。 また、スレーブのカスケード接続やスレーブからマスターへの切り替えが可能である。 Slony-Iのシステム構成は図1に示すとおりである。

図1: Slony-Iのシステム構成

機能の有効性

機能の有効性について、使用上の注意点などを含めて考察する。

レプリケーション

レプリケーション機能は非同期方式を採用しているため、データの更新はマスタとスレーブに対して同時には反映されず、多少ずれが生じる。従って、データの検索をマスタとスレーブに振り分けて負荷分散をするようなシステムで、検索結果がリアルタイムで一致している必要がある場合には使用できない。しかし、非同期方式はマスタがスレーブの同期処理を待たずにクエリを実行できるため、WANなどの低速なネットワークを挟んで遠隔地にスレーブを置いても、マスタの処理性能が低下しない利点がある。これは、バックアップの目的でレプリケーション機能を利用する場合に有用である。

レプリケーション機能にはいくつか制限がある。それらは、DDL操作がスレーブに反映されない、レプリケーション対象のテーブルに主キーが必要(ない場合はSlony-I側で用意することも可能)、ラージオブジェクトが複製されないなどである。これらはSlony-Iの仕組みによる制限だが、ラージオブジェクトの問題以外は代替案で解決できる。

カスケード接続

Slony-Iでのカスケード接続とは、スレーブにスレーブを繋げる接続のことである。Slony-Iは1台のマスタと複数台のスレーブでレプリケーションを行うことができるが、マスタとスレーブを直接接続するとマスタの負荷が大きくなる。それは、マスタで行われたデータ変更の情報を、複数台のスレーブに転送するためである。この問題の解決策として、カスケード接続が有効である。スレーブをカスケード接続することによって、マスタが情報を転送する先を減らすことができ、マスタの負荷を軽減できる。ただし、データの更新情報が複数のサーバを経由するようになるため更新が遅れ、ある時点でのデータベース間の差は大きくなる。

障害検知

Slony-Iにはslonプロセスの障害を検知して、自動的にslonプロセスを再起動するウォッチドッグスクリプトが用意されている。従って、それを使用すれば、slonプロセス障害によるレプリケーションの停止時間を短くすることができる。

DBサーバ障害やネットワーク障害を検知する機能はないが、Slony-Iを使用したシステムの構成ではフェイルオーバやスイッチオーバに人の判断が必要となるため、存在してもあまり意味がない。

スイッチオーバ

スイッチオーバ機能は、マスタの役割をスレーブに移動する機能のことである。スイッチオーバ実行後に旧マスタは、スレーブと同じ動作をする。

スイッチオーバ機能は、マスタサーバをメンテナンスするときなどに有用である。ただし、マスタサーバが他のサーバに移動するため、スイッチオーバ後はクライアントアプリケーションの接続先を旧マスタサーバから現マスタサーバに変更する必要がある。従って、クライアントアプリケーションを停止する必要があるが、マスタとスレーブの同期が取れている状態であればスイッチオーバは短時間で行われ、サービスの停止時間を短くすることができる。

フェイルオーバ

フェイルオーバ機能は、マスタの役割をスレーブに移動するという点ではスイッチオーバと同じであるが、マスタが壊れたことを前提としている点で異なる。マスタが壊れている場合は、スレーブがマスタと完全に同期することはできない。そのため、新マスタとなるスレーブは、他に一番同期状態の良いスレーブが存在すればそれと同期した上で新マスタとなる。フェイルオーバ実行後は、旧マスタは新マスタとの同期処理が行われなくなる。従って、旧マスタを再びマスタとして使用するには、一旦スレーブとして再構成して新マスタと同期した後、スイッチオーバを実施する必要がある。

PostgreSQLからの移行性

PostgreSQLからの移行性として、PostgreSQLを使用したクライアントアプリケーションをSlony-Iを使用した構成に移行する際に、クライアントアプリケーションが実行するSQLを修正せずに移行できるかということについて考察する。

データ定義コマンド

Slony-Iは、マスタのテーブル内のデータ変更を検知してから変更情報をスレーブに送信する仕組みのため、テーブルの作成や変更、削除といったデータ定義コマンドを使用するクライアントプリケーションはSQLの修正だけでは移行できない。ただし、それらのSQLをスクリプトとして用意し、それをslonikツールのEXECUTE SCRIPTコマンドに渡して実行するようにすれば移行できる。しかし、EXECUTE SCRIPTコマンドは実行時にレプリケーションセットの全てのテーブルにロックを要求するため、デッドロックが発生する可能性がある。

乱数値・現在の日付と時刻

Slony-Iはデータそのものを複製する方式のため、乱数値・現在の日付と時刻を使用するクライアントアプリケーションはそのまま移行することができる。

連番型・シーケンス

Slony-Iはデータそのものを複製する方式のため、連番型・シーケンスを使用するクライアントアプリケーションはそのまま移行することができる。

OID・ラージオブジェクト

OIDは、データベースのオブジェクトに対して割り当てられるIDである。Slony-Iは、導入時に様々なデータベースオブジェクトを生成するため、空のデータベースからレプリケーションを開始したとしてもOIDはマスタとスレーブでずれが生じる。従って、マスタとスレーブでOIDが一致していることを前提としたクライアントアプリケーションは移行できない。

なお、PostgreSQL 8.1以降では、ユーザのテーブルにOIDカラムを自動的に付加するdefault_with_oidsパラメータの初期値は無効に設定されている。また、もともとOIDをクライアントアプリケーションなどで使用することは推奨されていない。

トランザクションID

トランザクションIDはSELECTコマンドを実行するだけでも増加し、マスタとスレーブ間でトランザクションIDを一致させることは困難である。 従って、トランザクションIDが一致していることを前提としたクライアントアプリケーションは移行できない。

耐障害性

Slony-Iを使用したシステムに障害が発生した際の耐障害性について、データベースとしてのサービスを継続できるかという観点をもとに考察する。

slonプロセス障害

マスタ側、スレーブ側のどちらか、もしくは両方のslonプロセスが停止した場合、レプリケーションは行われなくなるが、サービスを継続することができる。ただし、そのまま継続するとマスタとスレーブ間のデータベース内容の差が大きくなるため、マスタとスレーブで負荷分散を行っているようなシステムでは注意が必要である。

ネットワーク障害・DBサーバ障害

スレーブサーバでネットワーク障害やDBサーバ障害が発生した場合は、スレーブをバックアップの目的で使用しているのであれば、マスタ側でサービスを継続することができる。一方、マスタサーバでネットワーク障害やDBサーバ障害が発生した場合は、データの更新処理を継続することはできない。しかし、フェイルオーバ機能やスイッチオーバ機能を使用して、データの更新処理の停止時間を短くすることはできる。

データ不整合

Slony-Iは非同期方式を採用しているため、ある時点でのマスタとスレーブ間のテーブル内容は一時的に一致しない状態になっている。従って、データ不整合の検知は行うことができない。また、Slony-Iは、直接スレーブに接続してデータを更新することができないようになっている。そのため、誤操作によりマスタとスレーブ間でテーブルが不整合の状態になり、サービスが停止する可能性は低いといえる。

障害復旧

障害後も停止せずにレプリケーションを再開することができる。復旧手順は障害を取り除くだけで済む場合が多く、自動的にマスタとスレーブ間の同期が取られるため容易である。また、マスタが壊れた時のためのフェイルオーバ機能も用意されており、マスタとスレーブ間で頻繁に同期処理が行われていれば、マスタサーバの障害時のデータ損失を最小限にすることができる。

このデータの性能データ

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

関連する考察データ

• pgbenchによるpgpool 3.1.1の運用性に関する評価結果の考察
• pgbenchによるpgpool 3.1.1、Slony-I 1.2.1の組み合わせの運用性に関する評価結果の考察