Slony-I は PostgreSQL の DSN をデータベースへのアクセス確立のため 2 つの型で使用します。
ADMIN CONNINFO - どのように slonik スクリプトが各種のノードをアクセスするのかを制御します。
これらの接続は使用している"管理用ワークステーション"から Slony-I クラスタ内の全てのノードに張られるものです。
そのネットワーク内のそれぞれかつ全てのノードへ slonik を走らせている中央の位置から接続を張ることは致命的です。そのような接続は、クラスタの管理を制御するのに必要とされる多少の SQL を発行するなど、瞬間的ににのみ使用されるものです。
これらの通信経路は瞬間的にのみ使用されるため、 SSH トンネル を使った暫定的接続と"一緒に絡める"ことはとても合理的です。
STORE PATH - 遠隔ノードで slon デーモン通信をどのように制御するか。これらの経路は sl_path に格納されます。
それぞれのサブスクライバノードとそのプロバイダ間の経路を持つことは強制的に必要です。その他の経路は任意で、sl_listen 内の監視経路が必要とされるその特定の経路に使用する以外には使われません。
経路の特質と可能性のある複雑性は、比較的に"包括的な"ネットワークアドレス集合を介して全てのホストがそれぞれ相手を見ている単純なネットワークをもっている人にとって、通常問題ではありません。 これとは対称的に、複雑なファイヤーウォール構成であるとか、複数の位置に跨るノードがあるとか、他の一様のネットワークアドレス集合を介してノードが全てお互いと話し合えない問題を抱えている場合には多少重大です。
6 つのノードを記述した添付の図表を検討してください。
DB1 と DB2 は、特別に管理された位置からを除いて外部からのアクセスに対しファイアーウォールのあるセキュアな"データベースレイヤ"にあるデータベースです。
DB1 はレプリケーションシステムのオリジンノードと仮定します。
DB3 は同じサイトの "DMZ" 内に存在します。そして、遠隔位置に対し Slony-I "プロバイダ"として使用される意図を持っています。
DB4 は補助/フェイルオーバサイトの "DMZ" 内にある DB3 の片一方です。現在の構成で、そのジョブは補助サイトのセキュアデータベースレイヤにあるサーバに"送り込み"を行うことです。
DB5 と DB6 は DB1 と DB2 に対する片一方ですが、現時点ではサブスクライバとして構成されています。
"主"サイトに災害が発生したとすると、補助サイトはそのデータを使用するアプリケーションサービスを引き継ぐように旨く構築されています。
勘定を支払う経営者としては補助サイトにあるマシンを単なる"バックアップ"とするには抵抗があるようです。疑いなくそれらのマシンを有効に使いたいと考え、実際にそう行動します。もし、主サイトが"トランザクション活動"に使用されていているのであれば、補助サイトのレプリカは多少の遅延が許される、時刻重視のレポート処理に使用されるでしょう。
構成の対称性が意味するところは、故障から保護されなければならない 2 つのトランザクションアプリケーションがあって、それは それぞれのサイトがあるアプリケーションに対し通常は"主"であるような追加のレプリケーションセットを率直に所有し、そこでは 1 つのサイトの崩壊は残りのサイトでサービスが結合されることに向けられることです。
ここで SSH トンネルの論考をする余地が残っています…。