8. Slony-I 待ち受け経路

注意: Slony-I 1.1 もしくはそれ以降のバージョンを稼働させているのであれば、構成のこの部分は自動的に管理される方式を導入済みのため、この節を読む必要は全くありません。それ以前のバージョンの場合は必要です。

ノードが2つ、3つ、もしくはそれ以上存在する場合、および如何なる程度であれカスケードされたサブスクライバ(例えば: サブスクライバノードを通じてサブスクライブを行うサブスクライバ)を使用する場合には、テーブル sl_listen の内容を管理する Slonik STORE LISTEN および DROP LISTEN 命令文で"待ち受け経路"を構成することに十分注意が必要です。

他のノードから伝播される事象を受け取るため、このテーブルの"リスナー"エントリは、それぞれのノードがどこで待ち受けを期待するかを管理します。更新を入手する"親"だけを待ち受ければよいと思うかも知れませんが、現実には複数の sync を全てから受け取られることを推断できるように全てのノードからのメッセージを受信できる必要があり、そのため sl_log_1 および sl_log_2 のエントリは全てに対して適用され、そして消去可能でなくてはなりません。この特別な通信は Slony-I がオリジンを他の位置に移行させることができるようにするために重要です。

8.1. 監視を中断するには

状況によって、サブスクライバノード(#2)を削除し再作成する必要があります。そのノードは他のサブスクライバ(#3)に対してデータプロバイダであって、効果敵には"カスケードされたスレーブ"でした。初期にサブスクライバノードを削除することは旨く行きません。と言うのは slonik がそれが従属ノードであると知らせてくるからです。そこで従属ノードをそのサブスクリプションセットに対して "マスター"ノードとして再指摘し、暫定的に問題なくレプリケートできるようにします。

その後、"ノード 2" のサブスクリプションを削除し、そしてそれを再サブスクライブ開始します。これで Slony-I set_subscription 事象を立ち上げ、テーブルのコピーを開始させます。その時点で適時に"ノード 3" に対し事象が伝播を停止し、完全に承認できる形式であるかぎり、何の事象もそれに対して発生しません。

問題はノード 3 がノード 2 から事象の受け取りを予期している場合で、set_subscription 事象の処理に追われ、何も渡せないからです。

ノード #2 を監視するノード #3 のリッスンルールを削除し、(レプリケーションセットに対するオリジンノードである)ノード #1 からくる事象を予測するルールと入れ換えます。その時点で、sync 事象をどこから入手するのかが判明するため、"手品のように"、ノード #3 はレプリケーションを再開始します。

8.2. 監視構成の方法

単純な場合は単純に対処できます。ここでは、より複雑なノード構成をみる必要があります。

1 から 6 までのノードの集合を考えてみます。ここで、1 はオリジンで、2-4 は直接オリジンからサブスクライブし、5 は 2 から、そして 6 は 5 からサブスクライブするとします。

ここにそれぞれのノードが他のそれぞれのノードから来るメッセージを監視するかを示した"リスナネットワーク"を示します。

       1|   2|   3|   4|   5|   6|
--------------------------------------------
   1   0    2    3    4    2    2 
   2   1    0    1    1    5    5 
   3   1    1    0    1    1    1 
   4   1    1    1    0    1    1 
   5   2    2    2    2    0    6 
   6   5    5    5    5    5    0 

2 行目はノード 2 に対する全てのリッスンルールを示しています。ノード 1、3、および 4 に対する事象を受け取り、1 に投げ、ノード 5 と 6 からの事象を ノード5 から受け取ります。

5 行目の最後、ノード 6 に対する項目は、ノード 6 はノード 1-5 から事象を受け取るためにノード 5 を監視することを示しています。

この"リスナネットワーク"を表現する slonik の set listen 命令文の集合は下記となります。

store listen (origin = 1, receiver = 2, provider = 1);
store listen (origin = 1, receiver = 3, provider = 1);
store listen (origin = 1, receiver = 4, provider = 1);
store listen (origin = 1, receiver = 5, provider = 2);
store listen (origin = 1, receiver = 6, provider = 5);
store listen (origin = 2, receiver = 1, provider = 2);
store listen (origin = 2, receiver = 3, provider = 1);
store listen (origin = 2, receiver = 4, provider = 1);
store listen (origin = 2, receiver = 5, provider = 2);
store listen (origin = 2, receiver = 6, provider = 5);
store listen (origin = 3, receiver = 1, provider = 3);
store listen (origin = 3, receiver = 2, provider = 1);
store listen (origin = 3, receiver = 4, provider = 1);
store listen (origin = 3, receiver = 5, provider = 2);
store listen (origin = 3, receiver = 6, provider = 5);
store listen (origin = 4, receiver = 1, provider = 4);
store listen (origin = 4, receiver = 2, provider = 1);
store listen (origin = 4, receiver = 3, provider = 1);
store listen (origin = 4, receiver = 5, provider = 2);
store listen (origin = 4, receiver = 6, provider = 5);
store listen (origin = 5, receiver = 1, provider = 2);
store listen (origin = 5, receiver = 2, provider = 5);
store listen (origin = 5, receiver = 3, provider = 1);
store listen (origin = 5, receiver = 4, provider = 1);
store listen (origin = 5, receiver = 6, provider = 5);
store listen (origin = 6, receiver = 1, provider = 2);
store listen (origin = 6, receiver = 2, provider = 5);
store listen (origin = 6, receiver = 3, provider = 1);
store listen (origin = 6, receiver = 4, provider = 1);
store listen (origin = 6, receiver = 5, provider = 6);

この命令文をどう読むかは以下のとおりです。

"レシーバ"ノード上で、"オリジン"ノードから来る事象を提供するために"プロバイダ"ノードの方を見る時点。

altperl スクリプト内の init_cluster ツールは slonik 命令文形式に加え、上記のような平坦な形式で最適化されたリスナネットワークを生成します。

この薔薇の集合の中には 3 つの"棘"があります。

8.3. 自動監視経路生成

Slony-I バージョン 1.1 では発見的手法が sl_listen エントリを自動生成するために導入されました。これは 3 つのデータソースに基づいて順番に起こります。

sl_subscribe または sl_path は何時でも変更できます。リスナ経路を更新するために RebuildListenEntries() が呼ばれます。

もし Slony-I の早期のバージョンを稼働しているのであれば、 項18.25 に注目すると良いかも知れません。これは、リスナ経路を生成するための slonik 要求を生成するスクリプト形式によるストアドプロシージャの機能を複製する Perl スクリプトです。