geek.conf.2

あるインフラエンジニアの備忘録

slony-Iをインストールしよっか

slony-Iとは・・・
postgreSQLのデータベース管理システムを非同期にレプリケーションするミドルウェアである。
そのレプリケーション方法はDBに、更新があった場合、ある関数を呼び出すように振舞うようPL/pgSQLをDBにインストールし、トリガー関数によってslony-Iを呼び出し、レプリケーション先にレプリケーションする方法となります。

このようにslony-IはDB非同期なためレプリケーション先へ同時にされることはありませんが、その遅延時間は気にするレベルではないです。

上記のレプリケーションの方法の説明にある更新についてですが、INSERT、UPDATE、DELETEを指します。

それでは以下から私がインストールした手順をば。

*OSはRHEL 5っす

・ユーザ設定
slony-I用にユーザを作成します。このユーザはslony-IがDBに接続する際に使用するユーザです。
ユーザ名は適宜で。
# su - slony1
$ vi .bashrc
→ 以下の設定を追記
SLONY1_HOME="/usr/local/slony1"
export PATH=$SLONY1_HOME/bin:"$PATH"

・インストール
ソースからコンパイルします。
configure optionは左から
インストールディレクトリ
postgreSQLの設定ファイルが配置されるディレクトリ
slony-Iの操作を容易にするperlスクリプト群をインストール
となります。
後にインストールディレクトリの所有者を変更します。
# tar jxvf slony1-1.2.21.tar.bz2
# cd slony1-1.2.21
# ./configure --prefix=/usr/local/slony1 --with-pgconfigdir=/usr/local/pgsql/bin --with-perltools
# make all
# make install
# chown -R slony1:slony1 /usr/local/slony1

次にslony-Iの設定を行います。
slony-I設定
slony-Iの設定ファイルをサンプルから作成し設定を行います。サンプルは上記インストール時のオプション

    • with-perltoolsによって作成されます。

合わせてログについても◎
# cd /usr/local/slony1/etc
# cp -p slon_tools.conf-sample slon_tools.conf
# vi /usr/local/slony1/etc/slon_tools.conf

-------------------------slon_tools.conf編集ここから-----------------------------
#このクラスタ名が付くスキーマslony-IはDBに作成する
$CLUSTER_NAME = 'replication';

#ログディレ
$LOGDIR = '/var/log/slony1';

#Apacheのrotatelogsをslony-Iのログに実行する
$APACHE_ROTATOR = '/usr/local/apache/bin/rotatelogs';

#マスター→スレーブへデータ更新するためのチェック間隔ms
$SYNC_CHECK_INTERVAL = 1000;

#デバッグレベル2がデフォルト、2だとシンクごと出力するためウザイる
$DEBUGLEVEL = 3;


☆追記:
と書きましたが、$DEBUGLEVELはver.1では未対応らしく以下のようにして
変更します。

#vi $POSTGRES_HOME/lib/slon-tools.pm

my $cmd = "$SLONY1_HOME/bin/slon -s $SYNC_CHECK_INTERVAL -d0 $CLUSTER_NAME '$dsn' 2>&1 ";

上記は-d2を-d0としてデバッグレベルを0としています。

ちなみにslony-Iをインストールすると$POSTGRES_HOME/libに以下のファイルが置かれます。
・slon-tools.pm
・slony1_funcs.so
・xxid.so
これらはslony-Iを動作させるのに必要なんです。(←あたりまえ)

追記終:

#マスタースレーブノード登録
#node3以降はコメントアウトする
$MASTERNODE = 1;
add_node( node => 1,
host => 'dbsrv1',
#↑IPアドレスの方がよい
dbname => 'DBNAME',
port => 5432,
user => 'slony1',
password => 'PASSWORD');
add_node( node => 2,
host => 'dbsrv2',
#↑IPアドレスの方がよい
dbname => 'DBNAME',
port => 5432,
user => 'slony1',
password => 'PASSWORD');


#クラスタセットset1について設定する。
"set1" => { 内

#各IDの開始番号を記述
"table_id" => 1,
"sequence_id" => 1,

#プライマリキーがあるテーブルを記述
"pkeyedtables" => [
'pk_tb'
],

#ユニークキーがあるテーブルをインデックスと共に記述
"keyedtables" => {
'uk_tb' => 'uk_tb_index'
},

#プライマリ/ユニークキーがないテーブルを記述
"serialtables" => ["tb"],
シーケンスを記述
"sequences" => {
'sq1',
'sq2'
},

-------------------------slon_tools.conf編集ここまで-----------------------------

上記でslon_tools.conf内に主キー、ユニークキー、キーなしテーブルを登録しますが、トリガー関数によるslony-I呼び出しを行う、つまりレプリケーション対象テーブルを定義しています。


# mkdir /var/log/slony1
# chown slony1:slony1 /var/log/slony1

これでslony-Iの方ではレプリケーション準備が整いました。
次回は実際にレプリケーションを走らせる手順です。あ、次回の前に・・・
以下にslony-Iインストール時一緒にインストールしたslony-Iの操作を容易にするperlスクリプト群の説明をします。

/usr/local/slony1/bin/

slon_kill →
slony-Iのサービスとwatchdogを停止する。引数はslon_tools.confに設定されたノード番号:iとか

slon_start →
slony-Iのサービスとwatchdogを開始する。引数はslon_tools.confに設定されたノード番号:1とか

slon_watchdog →
watchdogさを開始する。slon_startとともに実行される。

slon_watchdog2 →
watchdogよりも高機能なwatchdogを開始する。slony-Iも再起動される。

slonik_build_env →
node等を指定してslon_tools.confを作成する。引数は -node host名:DB名:ユーザ名:パスワード、DB情報から自動でテーブル等が反映されるので良いかも◎

slonik_create_set →
slonyクラスタセットを作成する。引数はslon_tools.confに設定されたセット名:set1といった。

slonik_drop_node →
slonyクラスタ内のノードを除外する。引数はノード番号

slonik_drop_sequence →
レプリケーション対象からシーケンスを除外する。引数はシーケンス名。たぶん。

slonik_drop_set →
slonyクラスタセットを削除する。引数はslon_tools.confに設定されたセット名

slonik_drop_table →
レプリケーション対象からテーブルを除外する。引数はテーブル名。たぶん。

slonik_execute_script →
DDL変更をslonyクラスタに設定する。引数は-c "CREATE TABLE ..." セット番号:1とか

slonik_failover →
slonyクラスタノードをフェールオーバさせる。引数は現マスタノード番号 新マスタノード番号となり、現マスタノードはslonyクラスタから切り離される。

slonik_init_cluster →
slonyクラスタを初期化する。

slonik_merge_sets →
2つのslonyクラスタセットをマージする。引数はマスタノード番号 マージ先セット番号 マージするセット番号

slonik_move_set →
slonyクラスタノードをスイッチオーバさせる。引数はセット番号 現マスタノード番号 新マスタノード番号であり、現マスタノードはスレーブノードになる。

slonik_print_preamble → 知らん教えてくれよ

slonik_restart_node → ノードのリスタート。引数はノード番号

slonik_store_node →
ノードをslonyクラスタに追加する。この際、DBにslony-Iが、スキーマを作成する。このスキーマ名には_replicationが付く。引数はノード番号

slonik_subscribe_set →
slonyクラスタのスレーブノードを設定する。引数はセット番号 ノード番号

slonik_uninstall_nodes →
slonyクラスタノード全てに対し、slonik_store_nodeによってslony-Iが作成したスキーマ、を削除する。非常に危険なスクリプトらしいよぉ&heart

slonik_unsubscribe_set →
slonyクラスタのスレーブノードを削除する。引数はセット番号 ノード番号であり、一時的にレプリケーションを停止したいときにどーぞ。

slonik_update_nodes →
いやぁシラネ、なんかslony-Iをバージョンアップしたときにその更新をslonyクラスタノードに知らせるために使うみたいよ?

slony_show_configuration → slon_tools.conf設定を確認し、標準出力する。
#他にslonとslonikがありますが、これはslony-I本体のインストール時に配置されるものです。


これらスクリプトは、slony-Iに適用すべき実行命令の生成のみで、実行するだけでは反映されない。
パイプ|でslonikに渡してやり反映させる。

例:$/usr/local/slony/bin/slonik_subscribe_set set1 2 | /usr/loca/slony1/bin/slonik