17. Slonik 不使用 - はだかの Slony-I 機能

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 のようなものにレプリケーションのサポートを追加)、どこに各種の関数が呼ばれる必要があるかに付いてよく判っていなければなりません。通常の"プロトコル(通信規約)"はこのようになります。