Slony-Iを利用する際の注意点

Slony-I PostgreSQL

Slony-Iは、意外と運用が難しいので、構築時、または運用時における、注意点をまとめておきます。

ロードバランス機能は提供されない

　複数のノードに対してデータの検索を振り分けたり、データの更新をマスタのみに送信したりするには、基本的にクライアントアプリケーションで対応する必要があります。この部分は、Pgpoolと連携する*1ことで実現することが多いです。

テーブル定義にはユニークキーが必須

　PKまたは、一意制約が指定されたカラムが必須です。もし、テーブル定義にない場合は、Slony-Iが勝手に専用カラムを追加し、一意となるキーを、これまた勝手に振る動作をします。
　よほどの理由が無い限りは、ユニークキーを用意すべきです。Slony-Iが自動でキーを振らなければならず、性能に影響が出る可能性があります。

テーブルの変更(DDL)はレプリケーションされない

　Slony-Iは、トリガーベースのレプリケーションのため、DDLはレプリケーションできません。従って、マスタ、スレーブの全ノードに対して、DDLを自分で配る必要があります。このあたりは、シェルで自動化すべきです。

SQLの制約

　Slony-IでのSQLの制約は、以下となります。
　　参考　http://ossipedia.ipa.go.jp/capacity/EV0612230251/

  • ラージオブジェクト(BLOB)を扱えない
  • OIDは利用できない
    • OIDは、データベースのオブジェクトに対して割り当てられるID
    • Slony-Iは、導入時に様々なデータベースオブジェクトを生成する
    • そのため、空のデータベースから開始したとしてもOIDはマスタとスレーブでずれる


　Slony-IにおけるSQLの制約は上記のみです。
　Slony-Iは、トリガーベースのレプリケーションのため、実行時に不定な関数（sysdate(),random()など）でも利用可能*2です。他のレプリケーション方式*3と比較しても、制約は少ないと言えます。

Slony-Iのレプリケーションは、トリガを使っているため、「すでにマスタノード上で行われた変更をレプリケーションする」という違いがあります。
　このためSlony-Iでは、random()やcurrent_timestampのような、実行してみるまで値が確定しない関数の結果をテーブルにINSERTした場合でも、マスタとスレーブ間で同じ値となります。

非同期レプリケーション！ | Think IT（シンクイット）
ただし

　別の項で、Pgpoolと連携させることが多いとを書きましたが、Pgpoolのバージョンによっては、日付関数は利用できない*4ので注意が必要です。

マスタの負荷に対する考慮

　Slony-Iは、1台のマスタと複数台のスレーブで、レプリケーションを行うことができますが、マスタと複数台のスレーブを直接接続するとマスタの負荷が大きくなってしまいます。マスタで行われたデータ更新を、複数台のスレーブに転送するためです。
　解決策としては、カスケード接続（チェーン接続）が有効です。スレーブをカスケード接続することで、マスタが情報を転送する先を減らし、マスタの負荷を軽減できます。
　但し、データの更新が複数のサーバを経由すると、最後のサーバにデータが到達するまでの遅延時間が大きく、マスタとスレーブ間の差異で問題が発生する可能性があります。

*1:参考URL⇒http://ossipedia.ipa.go.jp/capacity/EV0612230252/

*2:一度マスタに格納された（不定ではない）値をスレーブに送るため、実行時に不定な関数でも利用可能となります。

*3:MySQLや、Pgpoolのレプリケーションは、SQL（ステートメント）ベースであるため、実行時に不定な関数をSQL内で利用してはいけません。レプリケーションされる各スレーブノードで異なる値として、更新されてしまうからです。

*4:pgpool-II 2.3以降では、自動的にマスタ側から取得した時刻値に置き換えることでレプリケーションできるようですが、Pgpoolが日付をどのように書き換えるか不透明なため、使用しないのが無難と考えています。⇒ レプリケーションモードで注意が必要な関数など