4. 監視

ここに Slony-I ログ中に見つけられるいくつかを列挙してその意味を説明します。

4.1. CONFIG notices

これらのエントリはとても簡潔です。構成に関しての有益なメッセージです。

ログに送り込りこんだ典型的なエントリのいくつかを示します。

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

4.2. DEBUG 警告

デバグ警告は常にその警告の元となったスレッドの名前に続きます。以下のスレッドからのメッセージがあります。

localListenThread

<1-- This is the local thread that listens for events on the local node. --> これはローカルノードの事象を監視するローカルスレッドです。

remoteWorkerThread-X

リモート事象を処理するスレッド。このノードが通信するそれぞれのノードに対して以下のうちの1つが予測されます。

remoteListenThread-X

リモートノードのデータベースの事象の監視。クラスタ内のそれぞれのノードに対して以下のうち1つが予測されます。

cleanupThread

確認と事象テーブルの一掃、古いデータの削除などバキュームのようなことを扱います。

syncThread

SYNC 事象の生成。

4.3. Slony-I ログの読み方

slon に関しては「マスター」も「スレーブ」もないことに注意してください。それらは単にノードです。

最初に予想するのは、両方のノードで、何かの事象が行ったり来たり伝播するのを見ることです。第一に、ノードと経路の作成を示す何らかの事象の公布があるはずです。それらが認められない場合は、そのノードが他のノードと通信できなさそうで、何も起こりません。

その後、主として2つの種類の振る舞いが見られます。

書いてください:筆者は残りの部分の形式を決められません。スレッドがどう動くか、稼働させた後のログに何を期待するかなどの、たぶん「どのように作用するか」のページが必要でしょう。

4.4. Nagios レプリケーション検査

tools ディレクトリ内の pgsql_replication_check.pl と呼ばれるスクリプトは Nagios システム監視ツールにプラグインするためのレプリケーション検査を構築するいくつかの試みがなされた中で、最も優れた解決策を代表しています。

以前のスクリプト、test_slony_replication.pl は、"検査スクリプト"が定期的に走り、Slony-I の構成をオリジンとサブスクライバを見つけるためにくまなく探し、変更を注入し、そしてシステム全体の伝播を監視すると言う"賢い"手法を採用しました。2つの問題がありました。

新規スクリプト、 pgsql_replication_check.pl は規則的な"トラフィック"を監視するオンラインシステムであることを仮定した必要最小限の手法を採用しており、規則的な更新の監視が期待される replication_status と呼ばれるレプリケーション検査特定のビューを定義できるようになっています。ビューは単にノード上の最も直近の"トランザクション"を探し、そのタイムスタンプ、年齢、および参照した場合有用と思われるアプリケーション情報の一部を一覧させます。

スクリプトのインスタンスは監視されるそれぞれのノードで稼働する必要があります。これが Nagios が動く状態です。

4.5. test_slony_state

このスクリプトは準備段階であって、何らかの Slony-I クラスタの状態分析を常に行う必要がありそうです。

クラスタ上のいかなるノードと接続するために databasehostuserclusterpassword、および port を含む引数を指定します。同時に(Unixmailx と同等の)mailprog コマンドを指定し、電子メールの受け取り手となります。

そして、スクリプトはクラスタ内の全てのノードを見つけるのに sl_path をくまなく探し、DNS にそれを認めさせ、そして順次それぞれ全てに接続させます。

それぞれのノードで以下の物事を含む物事の状態をスクリプトは調査します。

スクリプト内のパラメータに基づく診断作業を確かにスクリプトは実行します。