3. ノードの購読

あるセットにあるノードを購読する前にプロバイダと新規の購読するノードの双方で slon プロセスが稼働していることを確実にしておく必要があります。もし slon が稼働していないと、何も起こらず、どうなっているのか理解するため壁に頭をぶつけることになります。

ノードをセットに購読するには slonikSUBSCRIBE SET コマンドを発行します。次のようにして1回の試みで複数のノードをあるセットに購読させたい誘惑にかられるかもしれません。

try {
  echo 'Subscribing sets';
  subscribe set (id = 1, provider=1, receiver=2, forward=yes);
  subscribe set (id = 1, provider=1, receiver=3, forward=yes);
  subscribe set (id = 1, provider=1, receiver=4, forward=yes);
} on error {
  echo 'Could not subscribe the sets!';
  exit -1;
}

ところがこのような形でセットの購読を試みることは問題を単に招き入れる結果となります。1回に1つのノードを購読するのが適切な手順で、次のノードのセットへの購読に移行する前にログとデータベースを検証します。同時に上記の slonik 試行ブロック内の "success" はノード2、3、および4が首尾よく購読されたことを意味しませんので、価値がありません。それは単にオリジンノードで走っている slon がうまく slonik コマンドを受けたことを示しているだけです。

引き起こされる問題の典型的なものは、まだ準備の整わないプロバイダをカスケードされた購読ノードが探しにゆくことです。この障害の場合購読ノードは決して購読ノード(訳注:プロバイダの誤り)を拾えません。過去に引き起こった事象を待ち続け"固まって"しまいます。他のノードは(それらノードにエラー報告が返されないため)うまく購読されたと確信するかもしれません。そのノードの購読停止要求は、ノードを購読しようとした時点で固まっているので"妨害"されます。

あるノードをあるセットに購読する時、プロバイダノードに対する slon ログの中に以下を見出すはずです。

DEBUG2 remoteWorkerThread_3: Received event 3,1059 SUBSCRIBE_SET

同時に購読するノードに対する slon ログの中には以下のログエントリを見出し始めるはずです。

DEBUG2 remoteWorkerThread_1: copy table public.my_table

<1-- It may take some time for larger tables to be copied from the provider node to the new subscriber. If you check the pg_stat_activity table on the provider node, you should see a query that is copying the table to stdout. --> プロバイダノードから新規の購読ノードに大きなテーブルをコピーするのにいくらか時間が掛かります。プロバイダノードの the pg_stat_activity テーブルを照会すれば、テーブルを標準出力(stdout)にコピーする問い合わせが見付かるはずです。

プロバイダと新規購読ノード双方にある sl_subscribe テーブルには、新規サブスクリプションに関するエントリを含んでいます。

 sub_set | sub_provider | sub_receiver | sub_forward | sub_active
---------+--------------+--------------+-------------+------------
      1  |            1 |            2 |           t |         t

最後の検証はオリジンノードのレプリケートされたテーブルの一つに行を挿入し、その行が新規購読ノードにコピーされたかの実証です。