ORA-28396
12cmの空洞に閉じ込められた僕です。
今宵はOracle10gR2のwalletについて。
walletはOracle Ent および Advanced Security Optionのライセンス買うと
利用できる。まぁ表領域をencryptionできるわけですな。
あんまやってるの見かけたことないけど顧客データとかあると
やっておいたほうがよいよね。
設定のやり方は
１．sqlnet.oraにwalletファイルの場所を書く。
------------------------------------------
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=/home/oracle/wallet)))
------------------------------------------
とか。
２．Oracle再起動
再起動後、/home/oracle/walletにewallet.p12という鍵ファイルが
できているかと。
３．walletのopen
SQL> alter system set encryption key identified by "geekconf";
４．openの確認
SQL> select * from v$encryption_wallet;
WRL_TYPE
------------------------------------------------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS
---------------------------
file
/home/oracle/wallet
OPEN
※walletをcloseする場合
SQL> alter system set encryption wallet close;
とするよろし。
５．オプション
Oracle再起動後も自動でwalletがopenするようにするには
Oracle Wallet Managerでwallet設定の自動オープンにチェック
をつけchina。
て感じ。
でこれOracleRACとかLifeKeeperのように2ノードでHAするとき
どうすんのよって思うじゃん。
2ノードとも上記のように設定してもフェールオーバ後、表領域のデータ
selectしたら表題のエラー
ORA-28362: master key not found
が出ちゃって暗号化解けないワロリンｗｗｗｗ
まぁさ、walletファイルの格納場所を共有Disk上に再設定および
作成したら解決したって話なのよ。もう2行で終わる話。
ようするにだ。2ノードのローカル上にwalletファイル置いていたら
フェールオーバ時に異なる鍵だよって言われちゃうわけ。あーゆーおｋ？
owari
Korg ZERO4 のご紹介
その距離が愛しい僕です。
さて今日はKorg-sanが発売し、もう生産していない名機。Korg ZERO4をご紹介いたします。
ZERO4はミキサなんですけど、オーディオI/O、MIDIコントローラ、エフェクターを備えた
機器なんですね。ミキサチャンネルが4つあって1つのチャンネル内でEQやレベルなどの
オーディオ信号処理と、MIDIコントロールを同時に行うことができます。
そしてFireWireオーディオ+MIDIモードを搭載。
これねーなにがいいってさ、見た目かっこいいでしょ？
つまみ(*´Д`)ﾊｧﾊｧ
iPodからZERO4のチャンネル1にLine入力してBOOTH OUTをスピーカーに出力しています。
たまにほかチャンネルにPC on Ableton Liveの音をFireWire入力してます。
これは2010年11月に￥50,000ほどで買ったんすけどすでに生産してなく。
最近修理出して復活させたんですけど自宅が好きになりました。
そのときの修理代をメモります。
修理依頼日：2013/07/26
故障原因：電源ユニット故障
修理代金：工賃→￥8,000、電源ユニット→￥3,000、送付手数料→￥1,000 合計→￥12,000
スペックはこのページ参照されたし⇒ZERO4/ZERO8 : 仕様｜KORG INC.:
完
ネットワークスペシャリスト (H24 秋)
IPAのネットワークスペシャリストに受かっていますのでログを取ります。
●ネットワークスペシャリスト (H24 秋)
「高度IT人材として確立した専門分野をもち、ネットワークに関係する固有技術を活用し、最適な情報システム基盤の企画・要件定義・開発・運用・保守において中心的な役割を果たすとともに、固有技術の専門家として、情報システムの企画・要件定義・開発・運用・保守への技術支援を行う者」と規定しております。
午前も午後I、午後IIも60%以上で合格です。
合格日：2012/12/XX(忘れた)
点数：午前：70% 午後I：60% 午後II：60%(このくらいだったと思われ)
勉強期間：56日(2012/08/26 - 2012/10/20)
利用した参考書：平成24年度 ネットワークスぺシャリスト パーフェクトラーニング過去問題集
2012 ネットワークスペシャリスト 「専門知識＋午後問題」の重点対策
2012 ネットワークスペシャリスト予想問題集
勉強方法：午前問題はパーフェクトラーニングの過去問やるだけ。午後問題は午後の重点問題を何週もして予想問題から苦手でかつ午後の重点問題と被らない問題を選別して勉強しました。勉強期間も短く、合格点ギリギリだったよ得した気分。名古屋で唯一達成した事柄かしら。
ありがとう鶴舞図書館。
XBA-3IPについて
お久しぶりです。
若くはないけどお金はあるから僕です。
本日はSonyのXBA-3IPというイヤフォンを買ったので本機について。
初めてのハイクラスイヤフォン購入です。
音、良いです！
このイヤフォンはバランスドアーマチュア、通称BAという駆動形式を採用しておりまして。
なんか補聴器によく使われているらしく、繊細な音の表現を可能としております。
不得意な音域として低音域がありますが、これをカバーするため、小型化であることからも
複数のBAドライバを利用します。本機は以下の3基のBAドライバを備えます。
・広域
・トゥイーター(高域)
・ウーファー(低域)
ちなみにBAドライバを4基備えるXBA-4IPてゆーのもありますが、上記に加えてスーパーウーファー(超低域)
が備わります。2基バージョン(XBA-2IP)ではトゥイーターなし。
ノイズキャンセラなしですが、ノイズブロックな構造で物理的にカバーしております。
デザインも良いので気に入りました。
解像度よろしい。
定価は￥26,000也なり。
最後にスペックを。
2013年7月 購入
≪ヘッドフォン部≫
式： 密閉トリプル・バランスド・アーマチュア型
ドライバーユニット：トリプル・バランスド・アーマチュア
感度： 108dB
再生周波数帯域： 4-28,000 Hz
インピーダンス： 12 Ω
最大入力： 100mW
コード長： 1.2ｍ（Ｙ型）
入力プラグ： iPod/iPhoneリモコン対応4極金メッキステレオミニプラグ
質量： 約7g
≪マイクロホン部≫
型式： エレクトレットコンデンサー型
指向特性： 全指向性
開回路電圧レベル： （0dB=1V/Pa） -42dB(0dB=1V/Pa)
了
PostgreSQL 9.1 Streaming ReplicationとPgpool-II 3.1を用いた自動フェールオーバ ソリューション
こんばんわ。早く今年が終わることを祈る僕です。
今回はPostgreSQL 9.1 Streaming Replication(SR)を実装してかつPgpool-II 3.1にて障害時に自動で待機系へフェールオーバさせるソリューション構築を書きます。
OSはRHELをイメージしてもらえれば。
PostgreSQL 9.1 SRを構成するノードはデータベースを提供するノードとそのデータベースのレプリケーション先のノードに分別されます。前者をマスターノード、後者をスレーブノードと言います。
前提としてマスター/スレーブノードでPostgreSQL 9.1はインストール済み。
マスターノードでデータベースも構築済み。とします。
※ホスト名はMasNod：マスターノード、SlaNod：スレーブノードとします。
※POSTGRES_HOME=PostgreSQLインストールディレクトリ
※PG_DATA=PostgreSQLデータベースディレクトリ
１．ユーザ作成と接続設定
レプリケーション用ユーザreplを作成してREPLICATION権限を付与します。
データベースが構築されているマスターノードでやれ。
[postgres@MasNod ~]$ psql -p 5432 -d postgres
=# CREATE ROLE repl LOGIN REPLICATION PASSWORD 'xxxxxx';
次にレプリケーション用の仮想データベースreplicationに接続許可する設定を行います。
マスターノードやれ。
[postgres@MasNod ~]$ vi $PG_DATA/pg_hba.conf
〜
# IPv4 local connections:
host replication repl 192.168.10.2/32 trust
〜
※アドレスはスレーブノードのもの。認証方式はtrustでもmd5でもお好みで。
２．マスターノードのSR設定
WALアーカイブログモードを使用します。普通使用します。そのようにディスクも確保しましょう。
マスターノードで。
[postgres@MasNod ~]$ vi $PG_DATA/postgresql.conf
〜
wal_level = hot_standby
max_wal_sender = 2
archive_mode = on
archive_command = 'cp "%p" $POSTGRES_HOME/archive/"%f"'
wal_keep_segments = 16
synchronous_standby_names = 'SlaNod'
〜
max_wal_senderはスレーブノード数+1としておく。
synchronous_standby_namesはレプリケーションを同期モードとするときに指定すべし。
これ以外はStreaming Replication Parameters Settingを参照されたし。
３．ベースバックアップのオンライン取得を開始
マスターノードのデータベースのベースバックアップのオンライン取得を開始する。
スレーブノードで
[postgres@SlaNod ~]$ pg_basebackup -h MasNod -p 5432 -U repl -D $PG_DATA --xlog --checkpoint=fast --progress
これ一発でスレーブノードのPG_DATAにマスターノードのPG_DATAの中身がコピーされます。まぁ便利。
PostgreSQL 9.0時代ではマスターノードでSELECT pg_start_backup('GEEK_SR');→scpかなんかでスレーブノードにマスターノードのPG_DATAの中身をコピー→マスターノードでSELECT pg_stop_backup(GEEK_SR);とやっていたのよ若者よ。
４．スレーブノードのSR設定
スレーブノードで
[postgres@SlaNod ~]$ vi $PG_DATA/postgresql.conf
〜
wal_level = hot_standby
〜
[postgres@SlaNod ~]$ cp -p $POSTGRES_HOME/share/recovery.conf.sample $PG_DATA/recovery.conf
[postgres@SlaNod ~]$ vi $PG_DATA/recovery.conf
〜
standby_mode 'on'
primary_conninfo 'host=MasNod port=5432 user=postgres application_name=SlaNod'
restore_command 'scp MasNod:$POSTGRES_HOME/archive/%f %p'
trigger_file '$PG_DATA/trigger'
〜
primary_conninfo内のapplication_nameはマスターノードのpostgres.conf内のsynchronous_standby_namesで指定した値を書け。これらはレプリケーションを同期モードで動作させるときに必要。
trigger_fileはスレーブノードの指定した場所にtriggerというファイル名のファイルがあればスレーブノードはレプリケーションを止めてデータベース更新可能となる。
または
[postgres@SlaNod ~]$ pg_ctl promote -D $PG_DATA
でスレーブノードを昇格させても同様にデータベース更新可能と出来る。
restore_commandはお好みで。
５．スレーブノードのPostgreSQL起動
６．レプリケーション確認
PostgreSQLのログからレプリケーションが出来ているか確認します。
マスター/スレーブノードで以下のメッセージが出ていればレプリケーション出来てます。
マスターノードで
LOG: replication connection authorized: user=postgres host=SlaNod port=5432
スレーブノードで
LOG: streaming replication successfully connected to primary
またはクエリで確認も出来ます。
マスターノードで
[postgres@MasNod ~]$ psql -p 5432 -d postgres
=# SELECT * FROM pg_stat_replication;
state列の値は以下のよう変化します。
startup：接続の確立中
backup：pg_basebackup中
catchup：過去のデータを更新中
streaming：リアルタイムデータを更新中
スレーブノードで
[postgres@SlaNod ~]$ psql -p 5432 -d postgres
=# SELECT pg_last_xact_replay_timestamp();
最後にデータがレプリケーションによって更新された時刻が表示されます。
ちなみにスレーブノードのデータベースを更新しようとすると以下のエラーが出て更新できない。
ERROR: cannot execute INSERT in a read-only transaction
７．自動フェールオーバソリューションの構築
ここまででPostgreSQL SRは構築できた。次にマスターノードの障害時にPostgreSQLデータベース利用者に意識させずにスレーブノードへ自動でフェールオーバさせるソリューションを構築する。
方法はslony-Iでフェールオーバ・・・からのぉぉ・・フェールバックしよっかで紹介したのと同様、Pgpool-IIのfailover_commandを使用します。
まぁPostgreSQLデータベースへの接続にはプロキシであるPgpool-II経由であることが前提ですが。
まずはPgpool-IIをPostgreSQL SR仕様にいたします。
※PGPOOL2_HOME=Pgpool-IIインストールディレクトリ
[postgres@AppNod ~]$ vi $PGPOOL2_HOME/etc/pgpool.conf
〜
replication_mode false
master_slave_mode true
master_slave_sub_mode 'stream'
failover_command '$PGPOOL2_HOME/bin/failover.sh %d %H $PG_DATA/trigger'
〜
以下に$PGPOOL2_HOME/bin/failover.shの中身をさらします。
------------------------------failover.sh--------------------------------------
#! /bin/bash
# Failover command for streming replication.
# This script assumes that DB node 0 is primary, and 1 is standby.
#
# If standby goes down, does nothing(do pgsql9 stop only). If primary goes down, create a
# trigger file so that standby take over primary node.
#
# Arguments: $1: failed node id. $2: new master hostname. $3: path to
# trigger file.
failed_node=$1
new_master=$2
trigger_file=$3
# Do nothing if standby goes down.
if [ $failed_node = 1 ]; then
slogin -i ~/.ssh/nopass-dsa SlaNod pg_ctl -D $PG_DATA -m immediate stop
exit 0;
fi
# Create trigger file.
slogin -i ~/.ssh/nopass-dsa MasNod pg_ctl -D /usr/local/pgsql/data -m immediate stop
slogin -i ~/.ssh/nopass-dsa $new_master /bin/touch $trigger_file
exit 0;
------------------------------------------------------------------------------
※環境変数宣言はお任せします。
このシェルはPgpool-IIがインストールされたホストで実行されますが、そのPgpool-IIホストからPostgreSQLホスト(=マスター/スレーブノード)へはパスワードなしでログインできるよう設定しておくことが、使用の前提条件です。
今回はtrrigerファイルを利用していますが、pg_ctl promoteのほうが直接データベースプロセスに働きかけるためフェールオーバも早いようです。
フェールオーバするとスレーブノード内のrecovery.confはrecovery.doneになります。
フェールバックは手動となりますが、フェールバックの時のためにマスター/スレーブノードの両ノードのpostgres.confとpg_hba.confとrecovery.confは$PG_DATA外にバックアップを取っておくことをお勧めします。
じゃこのへんで。
slony-Iでフェールオーバ・・・からのぉぉ・・フェールバックしよっか
こんばんわ、やっぱ人間働かないといろいろとダメっすね、ちっす僕です。
いやぁ世間は無職につめてぇつめてぇうぇっうぇっ
本日はpostgreSQL8.4系をconfigしたマスター/スレーブノード間のDBをslony-I1.2系を使用してレプリケーションして可用性をうまーしよーシリーズ最終章です。pgpool-IIは3系な！各章を以下に。
pgpool-IIをインストールしよっか、そして設定もしようよ
上記うちpgpool-IIをインストールしよっか、そして設定もしようよはレプリケーション中にサーバに障害発生時でも自動で正常サーバに切り替えること→フェールオーバの方法にまつわるetcなの。
平たく言うと、postgreSQLとwebアプリケーションとのプロキシとして振る舞うpgpool-IIにマスター/スレーブノードのヘルスチェックを行わせて、かつ接続先を制御(正常時はマスターノードへ)させて運用し、ノードに障害が発生したらpgpool-IIにあるコマンド(例：home/pgpool2/failover.sh)を実行させて即時に自動でフェールオーバしよーぜって。
で、本エントリーではもしもslony-Iレプリケーション中にノード障害が発生したら？について。
ケース１：スレーブノードの障害
スレーブノードには正常時だれも接続していない(pgpool-IIはヘルスチェックしているよ)ので主な作業としてはレプリケーションの再構築になります。
pgpool-IIが実行する/home/pgpool2/failover.shには本ケースのときはスレーブノードに対して
pg_ctl -D /usr/local/pgsql/data -m immediate stopとslon_killを実行しているのでpostgreSQLとslony-Iは停止しているはず。これを起動しますね。
１．スレーブノードのpostgreSQLとslony-Iの起動
詳細は割愛、レプリケーションができていることを確認してね。
２．pgpool-II再起動
ここがやっかいですが、pgpool-IIは一度障害と判断したノードが正常に戻っても自動でマスター/スレーブノードにくわえてくれません。故に再起動が必要です。
ちょっとさらに調査進めてここ改善できんか調べるさかい、お待ちください。もしくは情報お持ちでしたらコメントしていただけると助かります。
ケース２：マスターノードの障害
この場合、pgpool-IIは/home/pgpool2/failover.shを実行してマスター/スレーブノードを切替える。postgreSQLも停止している状態にする。
詳細にはpg_ctl -D /usr/local/pgsql/data -m immediate stopとslonik_failover 1 2 | slonik
であーる。
すると障害を起こしたマスターノード(元マスターノードと呼ぶ)はslony-Iからも切り離される。
なのでフェールバックは正常時のマスター/スレーブノードの構成にする必要がある。
さらに最新DBはマスターノードに昇格したスレーブノード(現マスターノードと呼ぶ)が持つのでこれも反映する必要もある。
ちなみにpostgreSQLの状態としては
元マスターノード→postgreSQL停止
現マスターノード→postgreSQL起動中
具体的には元マスターノードを現マスターノードのスレーブノードとして一旦再構築し、その後マスター/スレーブノードの関係を入れ替える。(スイッチオーバ)
※MasNod：マスターノード(元マスターノード)、SlaNod：スレーブノード(現マスターノード)
１．マスター/スレーブノードでslon_kill
[slony1@MasNod etc]$ slon_kill 1
[slony1@SlaNod etc]$ slon_kill 2
２．元マスターノードのpostgreSQLを起動
詳細手順割愛。
３．元マスターノードでDB再作成, createlang, テーブルスキーマ作成を実施
[slony1@MasNod etc]$ drop geekdb
[slony1@MasNod etc]$ create geekdb
[slony1@MasNod etc]$ createlang plpgsql geekdb
↑この行ではplpgsqlというslony-Iで使用する手続き言語を対象DBにインストールしている。
[slony1@SlaNod etc]$ pg_dump -s geekdb | psql -h MasNod geekdb
↑最後の行では現マスターノードのスキーマのみをダンプして元マスターノードにリストアしています。
ちょっと知ってる風テクっす。
４．マスター/スレーブノードのslon_tools.conf内のマスターノード設定値を現マスターノードに変更
[slony1@MasNod etc]$ vi /usr/local/slony1/etc/slon_tools.conf
$MASTERNODE = 1; => $MASTERNODE = 2;
[slony1@SlaNod etc]$ vi /usr/local/slony1/etc/slon_tools.conf
$MASTERNODE = 1; => $MASTERNODE = 2;
slony-Iにマスターノードを入れ替えることを教えるわけですな。
５．slonik_drop_nodeで元マスターノードを削除
[slony1@SlaNod etc]$ slonik_drop_node 1 | slonik
slony-Iに元マスターノード情報を削除せよと命令するわけですな。
６．slonik_store_nodeで元マスターノードにレプリケーション用スキーマを再作成
[slony1@SlaNod etc]$ slonik_store_node 1 | slonik
↑上記エラーとなった場合、本エントリー末に記載する対処を行う
７．slonik_drop_setでset1の情報を削除(現マスターノード側が持つset1情報クリアのため)
[slony1@SlaNod etc]$ slonik_drop_set set1 | slonik
８．slonik_create_setでset1の情報を再作成
[slony1@SlaNod etc]$ slonik_create_set set1 | sed s/"public."/"geekdb."/ | slonik
↑上記エラーとなった場合、本エントリー末に記載する対処を行う
９．マスター/スレーブノードでslon_start
[slony1@MasNod etc]$ slon_start 1
[slony1@SlaNod etc]$ slon_start 2
１０．slonik_subscribe_setでレプリケーション開始
[slony1@SlaNod etc]$ slonik_subscribe_set set1 1 | slonik
元マスターノードのスレーブを現マスターノードとするよう設定しているんですな。
レプリケーションが正常に動作することをSELECT文で見比べたりして確かめよう！
１１．マスター/スレーブノードのslon_tool.conf内のマスターノード設定値を元マスターノードに変更
[slony1@MasNod etc]$ vi /usr/local/slony1/etc/slon_tools.conf
$MASTERNODE = 2; => $MASTERNODE = 1;
[slony1@SlaNod etc]$ vi /usr/local/slony1/etc/slon_tools.conf
$MASTERNODE = 2; => $MASTERNODE = 1;
１２．slonik_move_setでマスターノードをスイッチオーバ
[slony1@SlaNod etc]$ slonik_move_set set1 2 1 | slonik
さて本エントリーの胆にようやくたどり着く。slonik_move_set 現マスターノードID 元マスターノードIDでスイッチオーバっす。一度は打ってみたいコマンドslonik_move_set！！ぼく当時打った後ドヤ顔だったと思います。
１３．pgpool-II再起動
１４．pgpool-IIからpostgreSQLにpsqlし、show pool_nodesで元マスターノードがpgpool-IIノードとして稼動していることを確認する
付録．手順６．slonik_store_nodeで元マスターノードにメタデータを再作成および手順８．slonik_create_setでset1の情報を再作成 作業時に発生するエラー対応
これは元マスターノードに対するDB再作成時、現マスターノードからpg_dumpによってスキーマ情報をリストアすると、slonik_store_nodeによって作成されるレプリケーション用スキーマが、すでに作成されているために重複して作成できない、という旨のエラーメッセージである。レプリケーション用スキーマはプレフィックス_replicationが付くんですな。
スキーマ情報をコピーした後にレプリケーション用スキーマを削除することで解消する。
[slony1@MasNod etc]$ psql geekdb -h MasNod -c "drop schema _replication cascade"
最後に．
さて当時はpostgreSQL9が未リリースでストリーミング・レプリケーション(SR)ができなかったためslony-Iをレプリケーションツールに採用しました。
僕のケースではこの採用は失敗に終わり、postgreSQL9リリース後にすぐにバージョンアップしてSRに移行しました。24/365システムで開発アプリも受託していたのでバージョンアップにはもろもろ調整含め苦慮しました。
僕のケースでは24/365、利用者数最大3万人のファイル管理システムでした。slony-Iレプリケーションで運用すると表側からでは異常でないのにpgpool-IIに異常と判断されフェールオーバが起こってしまい使い物になりませんでした。
好き勝手に書きますが、決してslony-I構築が悪かったわけと思っていません。開発アプリ言語にJava、その環境にc3poを使用し、開発アプリ内でもコネクションプールによってpostgreSQLとしゃべっていました。もちろんpgpool-IIでもコネクションプールします。この2重のコネクションプールおよびpgpool-IIのヘルスチェックの送受信かつマスター/スレーブノード間のトリガ関数によるslony-Iレプリケーションの相性が悪かったと思います。
postgreSQL純正であるSRにするとこの現象は起こらなくなりました。
僕のpostgreSQL人生の中でもいい勉強になった案件であったため本エントリーを作成しました。
次はpostgreSQL純正のSRについて掘り下げたエントリーで。ほいじゃ！
slony-Iでレプリケーションしよっか
こんばんわ、東京に帰ってきた人です。
今日はむかーしに紹介したpostgreSQLレプリケーションするslony-Iについて深堀します。
以下のエントリーの続きになるよね。
上記のエントリーのようにslony-Iインストール済が前提条件です。インストールパスなども上記エントリーを踏まえて本エントリーも記述します。
いよいよ２台のpostgreSQLがconfigされたサーバのデータベースをレプリケーションいたします。
レプリケーションする作業は/usr/local/slony1/bin/にあるperlツールをpostgreSQLユーザと関連するユーザ(ここではユーザ名slony1とします)で使用しますので/usr/local/slony1/bin/にパスを通しておくと◎
それではさくっとれっつすろーにー！
１．クラスタセットset1の初期化
/usr/local/slony1/etc/slon_tools.confで定義したクラスタセットset1について初期化します。
通常はクラスタセットはset1のみとなるはず。
マスターノードで。
[slony1@MasNod etc]$ slonik_create_set set1 | sed s/"public."/"geekdb."/ | slonik
CONTEXT: SQL statement "SELECT "_replication3".setAddSequence_int( $1 , $2 , $3 , $4 )"
PL/pgSQL function "setaddsequence" line 36 at PERFORM
ちなみにslonik_create_setはクラスタセットを作成する命令文でこの標準出力をslonikコマンドに渡してslonikコマンドがslony-Iにconfigしています。
sedコマンド部分は"public."を"geekdb."に置換しています。postgreSQLのデフォルトスキーマ名は
"public"ですが恐らくみなさん"public"でないと思うので適宜痴漢するよろし。
２．クラスタセットset1のサブスクライバ(スレーブノード)の設定
マスターノードで。
[slony1@MasNod etc]$ slonik_subscribe_set set1 2 | slonik
/usr/local/slony1/etc/slon_tools.confの中身を見てスレーブノードをconfigしているので
実行の前にusr/local/slony1/etc/slon_tools.confをちゃんと確認してね。
３．slony-I起動
マスターノードで。
[slony1@MasNod etc]$ slon_start 1
Invoke slon for node 1 - /usr/local/pgsql/bin//slon -s 1000 -d2 replication3 'host=MasNod dbname=geekdb user=slony1 port=5432' 2>&1 > /var/log/slony1/slony1/node1/slonydb-2010-09-17_20:13:24.log &
Slon successfully started for cluster replication3, node node1
PID [8401]
Start the watchdog process as well...
スレーブノードで。
[slony1@SlaNod etc]$ slon_start 2
Invoke slon for node 2 - /usr/local/pgsql/bin//slon -s 1000 -d2 replication 'host=SlaNod dbname=geekdb user=slony1 port=5432' 2>&1 > /var/log/slony1/slony1/node2/slonydb-2010-09-17_20:15:42.log &
Slon successfully started for cluster replication, node node2
PID [22651]
Start the watchdog process as well...
NOTICE: ALTER TABLE / ADD UNIQUE will create implicit index "tbl__Slony-I_replication_rowID_key" for table "tbl"
CONTEXT: SQL statement "alter table only "public"."tbl" add unique ("_Slony-I_replication_rowID");"
PL/pgSQL function "determineattkindserial" line 54 at EXECUTE statement
NOTICE: truncate of "public"."tbl" succeeded
NOTICE: truncate of "public"."tbl_pkey" succeeded
NOTICE: truncate of "public"."tbl_uniq" succeeded
これにてslonyプロセスがマスター/スレーブノードで起動します。
４．動作確認
ちゃんとレプリケーションできているか確認したいと思います。
マスターノードで。
# su - slony1
$ psql geekdb -q
slonydb=# INSERT INTO tbl VALUE (2,2);
スレーブノードで
# su - slony1
$ psql geekdb -q
slonydb=# SELECT * FROM tbl;
マスターノードでインサートしたデータが格納されていることを確認するよろし。
これで終いです。次回は自動フェールオーバ・・・からのぉぉ・・フェールバック(手動)について論じます。
