1.1 による新規機能の 1 つに、spool ディレクトリに保存できるログファイルとして、更新をシリアライズする能力です。
"スレーブシステム"にとって都合の良い、FTP、rsync、もしくは、たぶん 1GB の "USB メモリ"に記録し"鳥類輸送"システムのようなもので鳥の足に括って送り届けるなど、どんな方法を介してもスプールファイルを転送できます。
以下を含む、この形式でデータストリームに対応する数多くの洗練されたものがあります。
安全でないサイトへのレプリケーション
双方向通信が設定不可能な相手先へのレプリケーション
読み取り専用のトランザクションの取り除きや、重要でないテーブルの更新といった異なる形式の PITR(ポイントインタイムリカバリ)の提供
何らかの災害が発生した場合には、詳細を問い合わせのログで参照できます。
ログ送出のノードを実際に作成する異図がないとしても、このことは潜在的にログ送出を有用なものにします。
これはテストを遂行するための読み込みをおこすには本当に旨くできた状態です。
与えられたログ送出が考えられないほど安価になるデータの"エスクロウ(第三者預託)" システムがあります。
データに追加処理を行うため"切り離されたノード"上にトリガーを設定することができます。
例えば、かなり"正式な"データベースを取り上げ、 Richard T. Snodgrass による [Developing Time-Oriented Database Applications in SQL ] で記載されている技法を実装するトリガーを使用することにより、"暫定的な"ものに変えることができます。
-a オプションをつけることでどのような slon 購読ノードも生成可能です。
注意: これが意味する所は、ログ送出を使用するためには少なくとも 1 つの購読ノードが必要なことを覚えておいてください。
tools にある slony1_dump.sh というスクリプトは、サブスクライブノードの"現在の"状態をダンプするシェルスクリプトです。
ログ取得をオンにして購読ノードに対し slon を開始する必要があります。その後、何時でも slony1_dump.sh を実行させることができ、ある SYNC 事象の時点でその購読ノードの状態を抜き出します。ダンプがひとたび完了すると、ダンプが開始された時から生成された全ての SYNC ログは、"ログ送出購読"と連絡をつけるためにダンプに追加されます。
最初のリリースではかなり多くの限界がありました。リリースを重ねるにつれ、幸運なことに限界のいくつかは緩和もしくは解消されました。
ログ送出の機能は特定の購読ノードに適用されたデータを探知することになります。その結果、少なくとも 1 つの"正規の"ノードを持たなくてはなりません。オリジンと"ログ送出ノード"の集団のみから成るクラスタは所有できません。
"ログ送出ノード"は購読ノードに向かうトラフィックを完全に追跡します。複数のレプリケーションセットがある場合、事態を分割することはできません。
現在、"ログ送出ノード"は SYNC 事象のみ追跡します。このことはクラスタ構成のある変更に対応するのには充分ですが、他に対してはそうではありません。
ログ送出はある追加事象を処理しません、 以下に記載されている 1 つでもの事象が起こる絡みで、SYNC とslony1_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)かも、しかしそれほど単純である必要はありませんが。
注意: 以下に、どのようにログ送出を使用したいかについて、さほど整理されていないことを記述します。
何らか与えられた SYNC ファイルは確かなものではない可能性があるので、SYNC ファイルを盲目的に適用しようとはしませんね。もし不適当な場合、 setsyncTracking_offline() の呼び出しに失敗し、 psql セッションは ABORT し、そして、次のトランザクションに移行しようと試みられるように、 COMMIT もしくは ROLLBACK を探しだす SYNC ファイルの残りの部分を実行する結果になります。
とは言ってもファイルの全ての残りの部分は動かないことが判っています。
より良い考え方
ファイルの setsyncTracking_offline() 呼び出しの部分まで含む最初の数行を読み込む。
そこまでの適用を試みる。
失敗に終れば、続けても意味がありません。トランザクションを ROLLBACK し、最も近いファイルを検討します。
setsyncTracking_offline() 呼び出しに成功した場合は、次の正しい SYNC ファイルを取得して適用します。トランザクションを ROLLBACK し、psql で全ての更新のためファイル全体を適用させる必要があるかも知れません。
sync ファイルの最初の数行だけを捕捉する手法をサポートするために、"ヘッダ"情報の最後に複数のダッシュ(-)記号を持つように形式が設定されています。
-- Slony-I sync log -- Node 11, event 745 start transaction; select "_T1".setsyncTracking_offline(1, '744', '745'); --------------------------------------------------------------------