3. システム要求仕様

PostgreSQL が稼働するプラットフォームであればどんなプラットフォームでも Slony-I は動作します。

このリリース時点で特定のテスト結果を受け取ったプラットフォームは、FreeBSD-4X-i368, FreeBSD-5X-i386, FreeBSD-5X-alpha, osX-10.3, Linux-2.4X-i386 Linux-2.6X-i386 Linux-2.6X-amd64, Solaris™-2.8-SPARC, Solaris™-2.9-SPARC, AIX 5.1 および OpenBSD-3.5-sparc64 です。

Microsoft Windows™ 上で PostgreSQL が稼働しているホストで Slony-I が稼働に成功しているという報告があります。この時点では(例えば - slonikslon)バイナリアプリケーションは Windows™ で走りませんが、Unix に似たシステムのひとつで動いている slon から Windows™ 上で走っている PostgreSQL インスタンスに接続するのに困難を生じると言った理由はありません。

slonslonikWindows™ に移植することは大丈夫なはずです。マルチスレッド実行を持たせることで実現するため、slon に POSIX のような pthreads を実装させる懐疑的な挑戦があります。Windows™ 用の pthreads ライブラリがあるという報告がありますので、移植作業に自発的に申し出る興味を持った組織を拒むものはありません。

3.1. Slony-I のソフトウェア依存性

現在、PostgreSQL と同じように Slony-I をソースからサイト内でコンパイルできる必要があります。

Slony-I をコンパイルするには以下が必要です。

同時に十分なディスク容量があるかを確認します。ビルドとインストール過程でソースツリー用に約 5MB 必要です。

注意: バージョン 1.1 では PostgreSQL とは別に Slony-I をコンパイルできるようにする変更が進行中です。 LinuxFreeBSD のディストリビューションのメーカは事前にコンパイルされた Slony-I のバイナリパッケージを同梱できるので実利的になりますが、そうなるまでは本ソフトウェア関連バージョンをを全て自身でコンパイルする覚悟が必要です。

3.2. Slony-I ソースの入手

Slony-I ソースはhttp://developer.postgresql.org/~wieck/slony1/download/ より入手できます。

3.3. 時刻同期

レプリケーションクラスタ内で使用される全てのサーバはそれぞれの実時間時計を同期させる必要があります。こうすることでレプリケーション過程でサブスクライバが既にそのプロバイダより先に進んでいることを指摘するエラーメッセージを slon に出させないことを保証します。全てのノードで ntpd をはしらせ、そこでサブスクライバノードは"マスタ"プロバイダのホストを時刻サーバとして使用することをお薦めします。

Slony-I それ自身はちょっとした時刻の相違があっても機能しますが、システムを"同期状態"させる事は通常分散アプリケーションにとり非常に重要です。

NTP (ネットワーク・タイム・プロトコル)についてより詳しくは www.ntp.org を参照してください。

一部のユーザから問題の報告があり、たどり着いたところは PostgreSQL が認識しない何らかの時間帯を指示するロケールでした。

いずれにしても、 Slony-I (そして、PostgreSQL にも関連しますが)"最善の実施策"は postmaster のユーザ および/もしくは slon が走っている下のユーザは TZ=UTC または TZ=GMT を使用することです。これらの時間帯はどのようなプラットフォームでも確実にサポートされており、夏時間による時刻変更の時間の巻き上げを行わない"ローカル"時間帯に長所が認められます。

3.4. ネットワーク接続性

レプリケーションを行うホスト同士は PostgreSQL インスタンス間で双方向ネットワーク通信ができなければなりません。と言うことは、もしノード B がノード A をレプリケートしていれば、 A から B へと同時に B から A への経路が必要です。可能なかぎり Slony-I クラスタに属する全てのノードにこの種の、クラスタ内のどのノートから同じクラスタ内のどのノードへでも双方向通信を許可する事を推奨します。

構成を簡潔にするため、ネットワークアドレスは全てのノードに渡って理想的に一貫性を持つべきです。STORE PATH は確かに変更を許可しますが、同じサーバを指し示す複数経路を管理しようとしたとき、泥沼に落ち入ります。

この問題に取り掛かる手法の1つとして、ファイヤウォールルールを実装することが特に難しい環境では、それぞれの相手先に対し異るポートを使用し、127.0.0.1 の様なローカル IP アドレスを通して遠隔アクセスをを許可する SSH トンネルをそれぞれのホストに作成することでしょう。

slonikslon インスタンスはそれぞれが通信するために特別の接続やプロトコルを必要としません。これらは単に PostgreSQL データベースへのアクセスが必要で、システムテーブルを更新する能力を所有する"スーパユーザ"として接続できる必要があるだけです。

この通信モデルが示唆していることは Slony-I がその中で運用される全ての拡張されたネットワークが安全であるとして扱われなければならないことです。Slony-I ノードが"安全"だと判断したある遠隔地にあるデータベースを信用しない時、全てのクラスタに渡って逆に安全性について堅牢であるかが疑われます。"ピア・ツー・ピア"システムでは、クラスタ全体に影響を及ぼすレプリケーション事象を如何なるホストでも引き起こすことが可能です。ですから、クラスタに渡ったセキュリティポリシーは最も脆弱なリンクに対してのみ厳重にする配慮が必要です。安全性が確保されない分岐した位置にある Slony-I ノードはクラスタ全体に対し、安全性に関して妥協せざるを得ません。

Slony-I バージョン 1.1 で新しいことは、特定のレプリケーションセットの更新がログ送出と呼ばれるスキーマを介して直列化される機能です。sl_log_1 および sl_log_2に保存されるデータは同時にディスク上のログファイルに書き出されます。これらのファイルはその後希望するどんな方式ででも転送されます。例えば scp、FTP、DVD-ROM に焼いて郵送、または、くだらない限りの範囲で、 transmission of IP datagrams on avian carriers - RFC 1149 と同等に近い形式で、USB "フラッシュメモリー"に書き込んで伝書鳩に取りつけるなどです。しかし通信機構を採用していても、ログ送出を使用するサブルクライバが他の Slony-I ノードにアクセスする必要がないように一方向通信を認めています。