[pgcluster: 442] クラスタDB停止時のレプリケーションサーバの振る舞いについて
AOSHIMA Kentaro
pgcluster@ml.postgresql.jp
Wed, 04 Aug 2004 13:50:38 +0900
三谷様
皆様
いつも大変お世話になっております。
青嶋と申します。
吉田さんとともに検証をしております。
昨日ご報告させて頂いた件について、
av11への早速ご対応頂きましてありがとうございました。
別件ではありますが、お教え頂ければ幸いです。
＝＝＝はじめに＝＝＝
PGRsend_load_balance_packet内で、
ロードバランサのホスト名等がデバック文にて表示されないことから、
この部分で、オンコードにてロードバランサのホスト名を記述して
動作の確認を行いました。（av11で修正されたところでしょうか？）
（recovery.c PGRsend_load_balance_packet内でlbp->hostName等を
オンコードでロードバランサの設定を行いました）
＝＝＝事象＝＝＝
レプリケーションサーバが検知したクラスタＤＢのエラー（停止）を
ロードバランサに通知した際、ロードバランサはそのパケット内容を理解してい
ないのではという事象が発生致しました。
＝＝＝手順について＝＝＝
手順は以下のとおりです。
デバッグ文を埋め込みソースを追った経過も記載致します。
設定ファイルの詳細は文末に記載致しました。
(1)レプリケーション、クラスタDB（２つ）、ロードバランサの順で起動
ログ等にERRORはありませんでした。
(2)２台のクラスタDBのうち一つを停止した後、
クライアントから接続を行い、Insert文を発行
(3)レプリケーションサーバのデバック文を見たところ
停止しているクラスタDBへ数回レプリケートを行おうと試み、
接続不可能なため、停止したクラスタDBを"not ready"と見なしています。
(4)レプリケーションサーバは停止したDBに対して、
replicate.cのPGRset_host_statusにてDB_TBL_ERROR（-1）を設定します。
send_cluster_status_load_balance内でクラスタDBへの送信パケットの
packet_noをDB_TBL_ERROR と設定しています。
(5)PGRsend_load_balance_packetにて、
(4)で作成したパケットをロードバランサのRecoveryPortに向けて
送信しています。
(6)ロードバランサ側では、そのパケットをレシーブするものの
case文内で処理されずそのままスルーしているようでした。
その際の"received no"は、65535でした。
＝＝＝質問＝＝＝
クラスタDBのエラー検知・ロードバランサの振る舞いにについて
以下のように理解しております。
下記１，２理解のもとで、(1)〜(6)を考慮すると、
(6)のcase文にTBL_ERRORを設定する箇所が無いように思われるのですが、
如何でしょうか？
１ レプリケーションサーバが検知したクラスタDBのエラーを、
ロードバランサのRecoveryPortに向けて通知する。
２ １であるとした場合、
ロードバランサが受け取ったパケットは、set_recovery内で処理され、
ロードバランサが持つClusterTblの該当クラスタのuseFlagが
TBL_ERRORに設定され、以後振り分け対象としない。
以上、大変お忙しいところ恐縮ではありますが、
上記事象について、御教授頂ければ幸いです。
また、当方の理解不足による誤り等ございましたら、
ご指摘賜りたく存じます。
よろしくお願いいたします。
＝＝詳細情報＝＝＝
サーバの構成は以下の通りです。
・ロードバランサ1台
・クラスタDB2台
・レプリケーションサーバ1台
・テスト用マシン2台
・OS：RedHatEL AS3.0
・PGCluster1.0.7を使用
・全て同一セグメント上のLANに配置
=============== LB：pglb.conf ===============
<Cluster_Server_Info>
<Host_Name> dl1401 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 20 </Max_Connect>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> dl1402 </Host_Name>
<Port> 5432 </Port>
<Max_Connect> 20 </Max_Connect>
</Cluster_Server_Info>
<Backend_Socket_Dir> /tmp </Backend_Socket_Dir>
<Receive_Port> 5432 </Receive_Port>
<Recovery_Port> 7780 </Recovery_Port>
<Max_Cluster_Num> 5 </Max_Cluster_Num>
<Use_Connection_Pooling> no </Use_Connection_Pooling>
=============== DB1,DB2:cluster.conf ===============
<Replicate_Server_Info>
<Host_Name> gx240 </Host_Name>
<Port> 8777 </Port>
<Recovery_Port> 7778 </Recovery_Port>
</Replicate_Server_Info>
<Recovery_Port> 7779 </Recovery_Port>
<Rsync_Path> /usr/bin/rsync </Rsync_Path>
<Rsync_Option> ssh -1 </Rsync_Option>
<When_Stand_Alone> read_only </When_Stand_Alone>
=============== DB1,DB2:postgresql.conf ===============
max_connections = 5
port = 5432
=========== Replication：pgreplicate.conf ============
<Cluster_Server_Info>
<Host_Name> dl1401 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7779 </Recovery_Port>
</Cluster_Server_Info>
<Cluster_Server_Info>
<Host_Name> dl1402 </Host_Name>
<Port> 5432 </Port>
<Recovery_Port> 7779 </Recovery_Port>
</Cluster_Server_Info>
<LoadBalance_Server_Info>
<Host_Name> gx150 </Host_Name>
<Recovery_Port> 7780 </Recovery_Port>
</LoadBalance_Server_Info>
<Replication_Port> 8777 </Replication_Port>
<Recovery_Port> 7778 </Recovery_Port>
============================
青嶋 憲太郎 AOSHIMA Kentaro
aoshima.kentaro@nttcom.co.jp
============================