13. ログ送出 - ファイル付きの Slony-I

1.1 による新規機能の 1 つに、spool ディレクトリに保存できるログファイルとして、更新をシリアライズする能力です。

"スレーブシステム"にとって都合の良い、FTP、rsync、もしくは、たぶん 1GB の "USB メモリ"に記録し"鳥類輸送"システムのようなもので鳥の足に括って送り届けるなど、どんな方法を介してもスプールファイルを転送できます。

以下を含む、この形式でデータストリームに対応する数多くの洗練されたものがあります。

13.1. サブスクリプションセットに対する"スプールファイル"は何処に生成されるのでしょうか。
13.2. FAILOVER/ MOVE SET が起こるとき、何が起こりますか。
13.3. "スプール空間"を使いきってしまった場合はどうなりますか。
13.4. サブスクリプションをどう設定するのですか。
13.5. ログ送出の限界は何ですか。

13.1. サブスクリプションセットに対する"スプールファイル"は何処に生成されるのでしょうか。

-a オプションをつけることでどのような slon 購読ノードも生成可能です。

注意: これが意味する所は、ログ送出を使用するためには少なくとも 1 つの購読ノードが必要なことを覚えておいてください。

13.2. FAILOVER/ MOVE SET が起こるとき、何が起こりますか。

特別なことはありません。アーカイブしているノードが購読ノードのままである限りログを生成します。

13.3. "スプール空間"を使いきってしまった場合はどうなりますか。

この問題が緩和されるまで SYNC をノードは受け付けません。サブスクライブされているデータベースも同時に遅れます。

13.4. サブスクリプションをどう設定するのですか。

tools にある slony1_dump.sh というスクリプトは、サブスクライブノードの"現在の"状態をダンプするシェルスクリプトです。

ログ取得をオンにして購読ノードに対し slon を開始する必要があります。その後、何時でも slony1_dump.sh を実行させることができ、ある SYNC 事象の時点でその購読ノードの状態を抜き出します。ダンプがひとたび完了すると、ダンプが開始された時から生成された全ての SYNC ログは、"ログ送出購読"と連絡をつけるためにダンプに追加されます。

13.5. ログ送出の限界は何ですか。

最初のリリースではかなり多くの限界がありました。リリースを重ねるにつれ、幸運なことに限界のいくつかは緩和もしくは解消されました。

ログ送出の機能は特定の購読ノードに適用されたデータを探知することになります。その結果、少なくとも 1 つの"正規の"ノードを持たなくてはなりません。オリジンと"ログ送出ノード"の集団のみから成るクラスタは所有できません。

"ログ送出ノード"は購読ノードに向かうトラフィックを完全に追跡します。複数のレプリケーションセットがある場合、事態を分割することはできません。

現在、"ログ送出ノード"SYNC 事象のみ追跡します。このことはクラスタ構成のある変更に対応するのには充分ですが、他に対してはそうではありません。

ログ送出はある追加事象を処理しません、 以下に記載されている 1 つでもの事象が起こる絡みで、SYNCslony1_dump.sh によるダンプ間での関連性を無効にし、slony1_dump.sh を再実行する必要に迫られることを伴って、ログ送出はある追加事象を処理しません

  • SUBSCRIBE_SET

ログ送出がそれらに対応するような方法で、数多くの事象の型が処理されます。

  • SYNC 事象はもちろん処理されます。

  • DDL_SCRIPT is handled.

  • UNSUBSCRIBE_SET

    この事象は SUBSCRIBE_SET と同じ様にログ送出コードでは処理されません。とは言ってもその効果は、購読ノード上の SYNC 事象はそのセットに対して更新を含まないことです。

    同様に、SET_DROP_TABLE, SET_DROP_SEQUENCE, SET_MOVE_TABLE, SET_MOVE_SEQUENCE DROP_SET, MERGE_SET, は"適切に"処理します。

  • ノード構成に掛かり合う各種の事象はログ送出に無関係です。 STORE_NODE, ENABLE_NODE, DROP_NODE, STORE_PATH, DROP_PATH, STORE_LISTEN, DROP_LISTEN

  • どのようにして特定のセットが初期に構成されるかを記述するのに係わる事象も同様に無関係です。 STORE_SET, SET_ADD_TABLE, SET_ADD_SEQUENCE, STORE_TRIGGER, DROP_TRIGGER,

充分に通信しているフェイルオーバーすることができる Slony-I ノードに"ログが送出される"ノードを変更できれば素晴らしいことです。もし(たとえば)6 ノードのクラスタを構成しようとしていて、1 つの購読ノードの作成から始め、そしてその他 4つのノードを並行して同居させるためにログ送出を使用する、といった場合に非常に有用です。

この使用法はサポートされていませんが、予想するある方法としては、Slony-I 構成をそのノードに付け加え、そしてそれを新規ノードに格上げすることで実現されるかも知れません。もう一度、プログラム作成の単純な題材(Simple Matter Of Programming)かも、しかしそれほど単純である必要はありませんが。

13.1. ヒントの使用法

注意: 以下に、どのようにログ送出を使用したいかについて、さほど整理されていないことを記述します。