[pgcluster: 837] Re: リカバリモードでクラスタサーバがうまく起動しない場合の対応について

shimada_yuu @ tdc.co.jp shimada_yuu @ tdc.co.jp
2005年 11月 21日 (月) 09:26:34 JST


三谷様

返信誠に有難うございます。島田です。
開発された方からこうしてメールをいただけるなんてうれしいです。


2005/11/19 7:27:10,pgcluster-bounces @ ml.postgresql.jp wrote;
>rsyncの環境設定は完了していますでしょうか?
rsyncの環境設定は完了しております。
rsync -auzr -e "ssh -1" dual:/usr/local/pgsql/data /usr/local/pgsql
のコマンドを正常に行うことが出来ました


>レプリケーションサーバをデバッグオプション付き(-vn)で起
>動してみてください.リカバリーの進行状況が吐かれるはずで
>す.
>どこまで進んでいるか,または,どこに問題があるのかはデバ
>ッグ文から推測することができると思います.
>
↓こちらががマスタのレプリケータのログになります
[postgres @ testA home]$ pgreplicate -D /usr/local/pgsql/etc/ -vn
DEBUG:/usr/local/pgsql/etc//pgreplicate.sts open ok

DEBUG:PGR_Get_Conf_Data ok
DEBUG:LoadBalanceTbl allocate ok
DEBUG:PGRset_Conf_Data():CascadeTbl shmget ok
DEBUG:PGRset_Conf_Data():CascadeTbl shmat ok
DEBUG:PGRset_Conf_Data():CascadeInf shmget ok
DEBUG:PGRset_Conf_Data():CascadeInf shmat ok
DEBUG:PGRset_Conf_Data():CommitLog shmget ok
DEBUG:PGRset_Conf_Data():Commit_Log_Tbl shmat ok
DEBUG:Conf data read ok
DEBUG:PGRset_Conf_Data():HostTbl shmget ok
DEBUG:PGRset_Conf_Data():HostTbl shmat ok
DEBUG:PGRrecovery_main():PGRrecovery_main bind port 7778
DEBUG:replicate_main() 8777 port bind OK
DEBUG:cmdSts=N
DEBUG:cmdType=
DEBUG:port=0
DEBUG:pid=0
DEBUG:from_host=testA.tdc.co.jp
DEBUG:dbName=template1
DEBUG:userName=postgres
DEBUG:recieve sec=0
DEBUG:recieve usec=0
DEBUG:query_size=71
DEBUG:query=SELECT
PGR_SYSTEM_COMMAND_FUNCTION(1,'testA.tdc.co.jp',8777,7778)
DEBUG:sem_lock[1]
DEBUG:PGRis_same_host():not same host
DEBUG:PGRsend_replicate_packet_to_server():host(testA.tdc.co.jp) :
port(5431)
DEBUG:pgr_createConn():PQsetdbLogin host[testA.tdc.co.jp] port[5431]
db[template1] user[postgres]
DEBUG:PGRis_same_host():not same host
DEBUG:PGRsend_replicate_packet_to_server():host(testB.tdc.co.jp) :
port(5431)
DEBUG:pgr_createConn():PQsetdbLogin host[testB.tdc.co.jp] port[5431]
db[template1] user[postgres]
DEBUG:pgr_createConn():PQsetdbLogin ok!!
DEBUG:PGRsend_replicate_packet_to_server():connect db:template1 port:5431
user:postgres host:testA.tdc.co.jp query:SELECT
PGR_SYSTEM_COMMAND_FUNCTION(1,'testA.tdc.co.jp',8777,7778)
DEBUG:setTransactionTbl(): 5431 @ testB.tdc.co.jp is not ready
DEBUG:PGRsend_replicate_packet_to_server():setTransactionTbl failed
DEBUG:sem_unlock[1]


#リカバリ開始
DEBUG:pgrecovery_loop():recovery accept port 7778
DEBUG:pgrecovery_loop():receive packet no:1
DEBUG:first_setup_recovery():1st setup target testB.tdc.co.jp
DEBUG:first_setup_recovery():1st setup port 5431
DEBUG:first_setup_recovery():add recovery target to host table
DEBUG:PGRsend_load_balance_packet():host[testA.tdc.co.jp] port[7778]
DEBUG:first_setup_recovery():set RECOVERY_PGDATA_REQ packet data
DEBUG:PGRsend_replicate_packet_to_server():host(testA.tdc.co.jp) :
port(5431)
DEBUG:pgr_createConn():PQsetdbLogin host[testA.tdc.co.jp] port[5431]
db[template1] user[postgres]
DEBUG:pgr_createConn():PQsetdbLogin ok!!
DEBUG:PGRsend_replicate_packet_to_server():connect db:template1 port:5431
user:postgres host:testA.tdc.co.jp query:VACUUM
DEBUG:PGRsend_replicate_packet_to_server():sync_command(SELECT
PGR_SYSTEM_COMMAND_FUNCTION(3,0,0,1) )
DEBUG:PGRsend_replicate_packet_to_server():PQexec send :VACUUM
DEBUG:first_setup_recovery():send packet to master testA.tdc.co.jp
recoveryPort 7779
DEBUG:first_setup_recovery():wait answer from master server
DEBUG:first_setup_recovery():get answer from master:no[3]
DEBUG:PGRsend_load_balance_packet():host[testA.tdc.co.jp] port[7778]
DEBUG:pgrecovery_loop():1st master testA.tdc.co.jp - 5431
DEBUG:pgrecovery_loop():1st target testB.tdc.co.jp - 5431
DEBUG:pgrecovery_loop():receive packet no:5
DEBUG:pgrecovery_loop():2nd master testA.tdc.co.jp - 5431
DEBUG:pgrecovery_loop():2nd target testB.tdc.co.jp - 5431
DEBUG:pgrecovery_loop():second_setup_recovery end :1
DEBUG:pgrecovery_loop():recovery accept port 7778
DEBUG:pgrecovery_loop():receive packet no:1
DEBUG:first_setup_recovery():1st setup target testB.tdc.co.jp
DEBUG:first_setup_recovery():1st setup port 5431
DEBUG:first_setup_recovery():already recovery job runing
DEBUG:send_packet():PGR_Create_Socket_Connectsock[-1] host[testB.tdc.co.jp]
port[7779]
DEBUG:send_packet():PGR_Create_Socket_Connectsock[-1] host[testB.tdc.co.jp]
port[7779]
DEBUG:send_packet():PGR_Create_Socket_Connectsock[-1] host[testB.tdc.co.jp]
port[7779]
DEBUG:send_packet():PGR_Create_Socket_Connectsock[-1] host[testB.tdc.co.jp]
port[7779]
DEBUG:send_packet():PGR_Create_Socket_Connectsock[-1] host[testB.tdc.co.jp]
port[7779]
ERROR:send_packet():send failed and PGR_Create_Socket_Connect failed
DEBUG:pgrecovery_loop():1st master testA.tdc.co.jp - 5431
DEBUG:pgrecovery_loop():1st target testB.tdc.co.jp - 5431
DEBUG:pgrecovery_loop():recovery accept port 7778
DEBUG:pgrecovery_loop():receive packet no:3

>>
>> 相談内容としては
>> 1.クラスタサーバを再起動するときにロードバランサやレ
>プリケーションサーバ
>> は落とす必要がないのか?
>リカバリーにはロードバランサとレプリケーションサーバが必
>要です.
>特にレプリケーションサーバが動いていないとリカバリーでき
>ません.
>
とめる必要は無いということですね。
了解いたしました。

>>
>> 2.リカバリモードで立ち上げようとしたとき場合によって
>はレプリケーション
>> サーバにinitializeのステータスが
>>  ついたのですが、 postgresSQL必須テクニックスにかい
>てあったような
>> <サーバ
>> 名>can useのログが表示
>>  されませんでした。
>>  こちらの仕組みについてご教授いただけないでしょうか?
>リカバリーが完了したかどうかは,クラスタDBにしか分からな
>いので,リカバリーが完了した時点でクラスタDBはレプリケー
>ションサーバに「完了通知」を送ります.これを受けてレプリ
>ケーションサーバはリカバリー中に溜まったクエリーがあれば
>,これらを実行します.
>全部終わると,<サーバ名> can useをステータスファイルに書
>き出します.
>
>> 3.このままの状態で1つのクラスタサーバで片側運転を続
>けた場合に、復旧する
>> 最適な方法はないでしょうか?
>クラスタDBが2台の場合,生き残っている方がマスタDBになり
>ます.
>レプリケーションサーバを後から追加しても認識しますので,
>いつでもリカバリー可能です.
>
>安定版である1.0は,1.0.10rc1が最新ですので,こちらを試さ
>れることをお勧めします.
>

 もうひとつのスレッドで浅羽様に同様の質問を書いておりますが
 こちらでも念のため書きます

 pgclusterのページには1.0.9aが最新とあったのですが、pgFoundryのページを
 みたらありました。出来れば、本家のページも差し替えられたほうがユーザに
 はわかりやすいかと考えます。

仮に、1.0.9aから差し替える場合は一回、pgclusterを入れ替えなければならないの
でしょうか?


以上、お手数をお掛けいたしますが 宜しくお願い致します







pgcluster メーリングリストの案内