ここに Slony-I ログ中に見つけられるいくつかを列挙してその意味を説明します。
これらのエントリはとても簡潔です。構成に関しての有益なメッセージです。
ログに送り込りこんだ典型的なエントリのいくつかを示します。
CONFIG main: local node id = 1 CONFIG main: loading current cluster configuration CONFIG storeNode: no_id=3 no_comment='Node 3' CONFIG storePath: pa_server=5 pa_client=1 pa_conninfo="host=127.0.0.1 dbname=foo user=postgres port=6132" pa_connretry=10 CONFIG storeListen: li_origin=3 li_receiver=1 li_provider=3 CONFIG storeSet: set_id=1 set_origin=1 set_comment='Set 1' CONFIG main: configuration complete - starting threads
デバグ警告は常にその警告の元となったスレッドの名前に続きます。以下のスレッドからのメッセージがあります。
<1-- This is the local thread that listens for events on the local node. --> これはローカルノードの事象を監視するローカルスレッドです。
リモート事象を処理するスレッド。このノードが通信するそれぞれのノードに対して以下のうちの1つが予測されます。
リモートノードのデータベースの事象の監視。クラスタ内のそれぞれのノードに対して以下のうち1つが予測されます。
確認と事象テーブルの一掃、古いデータの削除などバキュームのようなことを扱います。
SYNC 事象の生成。
slon に関しては「マスター」も「スレーブ」もないことに注意してください。それらは単にノードです。
最初に予想するのは、両方のノードで、何かの事象が行ったり来たり伝播するのを見ることです。第一に、ノードと経路の作成を示す何らかの事象の公布があるはずです。それらが認められない場合は、そのノードが他のノードと通信できなさそうで、何も起こりません。
2つのノードの作成
slon がまだ稼働していません。ですから見るべきログはありません。
2つの slon の開始
いずれのノードもあまり話すことがないのと、他のノードとどのように話すかを知らないので、それぞれのログはおだやかに開始します。
通信経路のため STORE PATH を行います。この操作でノードが他のノードの認識を開始します。
バージョン 1.0 では sl_listen は自動設定されず、明示的にt STORE LISTEN 要求が発行されるまで何も起こりません。バージョン 1.1 では"監視経路"は自動的に設定され、より迅速に通信ネットワークが立上り、稼働します。
それぞれのノードの sl_node および sl_path および sl_listen テーブルの内容を参照すれば、どこに物事が立脚しているかのよい概念が掴めます。slon が開始する前は、それぞれのノードは一部分のみしか構成されません。2つのノードがある場合、ひとたび通信構成が正しく設定されれば、3つのこれらのテーブルに2つのエントリができるはずです。これより少ないエントリの場合には何が欠けているかのなんらなの指針を与えてくれます。
必要であれば、(例えば - バージョン 1.1 以前で)STORE LISTEN 要求を発行し、どのようにノードが通信経路を使用しているかを示さすことができます。
一度行われると、ノードのログは定期的な1つのノードや他のノードで開始された事象とか、他への伝播とかの、より大きな活動レベルを表示することになります。
セット(CREATE SET)、テーブルの追加(SET ADD TABLE)、およびシーケンス(SET ADD SEQUENCE)の設定ができ、セットに対するオリジンノードにのみ関連のある事象が見られます。
そこで、SUBSCRIBE SET 要求を発行した時に事象は両方のノードに動きます。
その後オリジンノードはもう少し多くのやらなければ成らないことがあります。次にサブスクライバは COPY_SET 事象を持ち、それぞれのテーブルへの追加とそのデータのコピーに関する情報のログを取得するようになります。
その後、主として2つの種類の振る舞いが見られます。
オリジン側にはそれほど沢山のログは出ず、単にいくつかの SYNC 事象が生成され他のノードで確認されたという指示だけです。
サブスクライバ側には SYNC 事象の報告があり、サブスクライバは関連性を有するセットに対するデータをプロバイダから引き込みます。オリジンノードへの更新がない場合は、これは頻繁に起こりません。オリジンが大量の更新に遭遇した場合、頻繁に起こります。
書いてください:筆者は残りの部分の形式を決められません。スレッドがどう動くか、稼働させた後のログに何を期待するかなどの、たぶん「どのように作用するか」のページが必要でしょう。
tools ディレクトリ内の pgsql_replication_check.pl と呼ばれるスクリプトは Nagios システム監視ツールにプラグインするためのレプリケーション検査を構築するいくつかの試みがなされた中で、最も優れた解決策を代表しています。
以前のスクリプト、test_slony_replication.pl は、"検査スクリプト"が定期的に走り、Slony-I の構成をオリジンとサブスクライバを見つけるためにくまなく探し、変更を注入し、そしてシステム全体の伝播を監視すると言う"賢い"手法を採用しました。2つの問題がありました。
検査を走らせるとレプリケーションが破壊されたように見える単一ホストへの接続性の問題。全体として、この監視手法は数多くのエラー状態に対し脆弱でした。
Nagios は自動的にノードのセットを探査する"賢さ"の恩恵をうける能力がありません。
新規スクリプト、 pgsql_replication_check.pl は規則的な"トラフィック"を監視するオンラインシステムであることを仮定した必要最小限の手法を採用しており、規則的な更新の監視が期待される replication_status と呼ばれるレプリケーション検査特定のビューを定義できるようになっています。ビューは単にノード上の最も直近の"トランザクション"を探し、そのタイムスタンプ、年齢、および参照した場合有用と思われるアプリケーション情報の一部を一覧させます。
在庫管理システムでは、それは最も最近に処理された注文に対する注文番号でしょう。
ドメインレジストリでは最も最近に作成されたドメインの名称になります。
スクリプトのインスタンスは監視されるそれぞれのノードで稼働する必要があります。これが Nagios が動く状態です。
このスクリプトは準備段階であって、何らかの Slony-I クラスタの状態分析を常に行う必要がありそうです。
クラスタ上のいかなるノードと接続するために database、 host、user、 cluster、password、および port を含む引数を指定します。同時に(Unix の mailx と同等の)mailprog コマンドを指定し、電子メールの受け取り手となります。
そして、スクリプトはクラスタ内の全てのノードを見つけるのに sl_path をくまなく探し、DNS にそれを認めさせ、そして順次それぞれ全てに接続させます。
それぞれのノードで以下の物事を含む物事の状態をスクリプトは調査します。
sl_listen を何かの"分析の結果確定できる"問題点のために検査します。
オリジンノードによる事象の要約提供
ある期間ノードがいかなる事象も提出しないのであればおそらく問題があることを示唆しています。
テーブル sl_confirm の "老化" を要約します。
もしクラスタ内の1つもしくは他のノードが最近報告を返してこない場合、sl_log_1 および sl_seqlog テーブルに掃除が行われていない傾向を示しています。
どのトランザクションが長期に渡って走っているかの要約
<1-- This only works properly if the statistics collector is configured to collect command strings, as controlled by the option stats_command_string = true in postgresql.conf . --> これは統計収集器が、postgresql.conf の stats_command_string = true オプションで管理されるように、コマンド文字列を収集するように構成されている時のみ適正に動きます。
接続がそのまま継続している壊れたアプリケーションを抱えている時、それを探してくれます。
接続がそのまま継続している壊れたアプリケーション持っていて、 の様ないくつかの解決できない作用は FAQ に書かれています。
スクリプト内のパラメータに基づく診断作業を確かにスクリプトは実行します。