Slony-I の数多くの部分品を実装する組み込み関数を直接使用することが意味をなす事例がいくつかあります。Slonik はそれほど多くの素晴らしいことを行いません。Slonik コマンドは、コマンドを適用するノード上で単に掛かり合い、そして Slony-I 組み込み関数の 1 つを呼び出す SQL 問い合わせを発行するのが共通した機能です。
Slony-I の開発者たちは Slonik の代替として、興味を持った仲間がグラフィックツール開発の望みを抱く事を期待しています。組み込み関数で直接構成要求を出すような場合は全く適切です。
"障害の起こった" Slony-I クラスタで問題のデバッグを行う時、組み込み関数を使用すると有効である事が時たま証明されています。特に sl_listen 構成が壊れていて、事象が適切に伝播されないような場合に有効でです。"最も手軽な"処理は以下のようになります。
select _slonycluster.droplisten(li_origin,li_provider,li_receiver) from _slonycluster.sl_listen;
select _slonycluster.storelisten(pa_server, pa_server, pa_client) from _slonycluster.sl_path;
この一連の問い合わせの結果は監視経路を再生成し、そして伝播させます。メイン _slonycluster.storelisten() 関数を実行する事で、STORE_LISTEN 事象はクラスタ内の他のノードに監視経路を伝播させる要因をもたらします。
もしも、1 つのノード上に局地的な問題があり、伝播の更新を望まない場合(普通でない情況であらゆる所での問題解決を行いたいのはほぼわかりきっている)、問い合わせは、その代わりに次のようになります。
select slonycluster.droplisten_int(li_origin,li_provider,li_receiver) from _slonycluster.sl_listen;
select _slonycluster.storelisten_int(pa_server, pa_server, pa_client) from _slonycluster.sl_path;
その他のツールに Slony-I サポートを追加しようと計画しているのであれば(例えば - pgAdmin III のようなものにレプリケーションのサポートを追加)、どこに各種の関数が呼ばれる必要があるかに付いてよく判っていなければなりません。通常の"プロトコル(通信規約)"はこのようになります。
"メイン"関数(例えば - _int サフィックスの付かない)が Slony-I クラスタ内の"関連のある"ノード上で呼ばれる。
場合によっては、関数は如何なるノードでも呼ばれ、他のノードに満足した形で伝播します。例を挙げると、schemadocstorelisten( integer, integer, integer ) では当てはまります。その他の場合として、データが理屈に一致して検証されるための、そこがたったひとつの場所である、なんらかの特定なノードで呼ばれる必要があります。例えば、schemadocsubscribeset( integer, integer, integer, boolean ) はレシーバノードで呼ばれなければなりません。
"メイン"関数が成功すれば、構成変更はローカルノードで実行され、Slony-I クラスタのその他の全てのノードに構成変更を伝播させる事象が、schemadoccreateevent( name, text ) で作成されます。
第 3 番目に、_int バージョンの関数が実行されなければなりません。
関数が巾等(idempotent)であるようなある事例では、"メイン"関数が実行されるノードで、処理の比較的速い段階でこれが行われます。
事象が伝播する時、他のノードで _int バージョンが実行されたら、旨く行くようにむしろ期待します。