概要

• レプリケーション設定はslonikコマンドで行う。
• slonikコマンドでは、Slony-Iの動作を管理する情報を管理テーブルに設定する。
  • 管理テーブルはレプリケーション対象のDB内にSlony-I用のスキーマを構築し、その中に構築する。
• 実際にレプリケーション動作を行うのはslonコマンド。
• slonコマンド内で管理テーブルを参照し、変更内容に該当するクエリを作成してレプリケーションしている(はず)

調査環境

• Slony-Iのバージョンは1.2.1
• レプリケーション対象となるPostgreSQLのバージョンは8.1.5

レプリケーションの例

レプリケーションの動き

1. slave側のslonはslave側のsl_eventを参照してイベントが生成されてないかチェックする。
   1. イベントが生成されてなければrollbackする。
   2. この動作をslonプロセスの監視スレッド内で繰り返し行う。(たぶん)
2. slave側のsl_action_seqを参照して(たぶん)シーケンス更新があったかチェックする。
3. slaveからlistenステートメント発行。これはまだ不明。
4. slave側でcon_timestampを参照。この目的は解析要。たぶんmaster(con_origin)とslave(con_recieve)の最新の更新状況を比較するためだと思うが･･･。
5. masterがforwardConfirm()を発行。転送が確定したタイムスタンプ？を取得するのか。
6. masterがcreateEvent()を発行。この中でおそらくイベントを生成し、sl_eventテーブルに書き込んでいるのであろう。
7. masterがsl_eventを検索。ここで先に生成したイベントを検知すると思われる。見つからなかったらたぶん何もしないと思われる。
8. masterでcon_timestampを参照。最新の更新状況の比較か？
9. 以降、masterでは監視スレッドがsl_eventを再度監視し始める。
10. slaveがsl_setsyncを参照。
11. slaveがsl_tableを参照。
12. slaveがsl_log_statusを参照。last_valueを取得しているので最新のステータス情報を得ているのか？
13. slaveがレプリケーション用のinsert文を発行。これで一つのレプリケーションが完了する。