[pgsql-jp: 35265] Re: pgpoolのreplication_stop_on_mismatch について
Tsunehisa Kazawa
kazawa @ ca2.so-net.ne.jp
2005年 4月 16日 (土) 11:43:23 JST
こんにちは。加澤と申します。
Tatsuo Ishii wrote:
> もしかして load_balance_mode がtrueになっていますか?それだとどちらか
> のサーバにしか問い合わせを発行しませんから,結果の照合ができず,エラー
> の検出はできません.
この一連のスレッドは大変ためになりました。
僕もこれまで load_balance_mode = true でテストしていたのですが、データ保
全を考え false にしてみることにしました。
***
ところで false に変えてテストを開始してみたところいきなり mismatch で縮
退してしまい、あぁ、実は不整合していたのだな、ということが分かったのです
が、その後リカバリ処理をして再びテストをしていると、この設定(※)ですと
insert と select が入り乱れる状況ではかなりの頻度で縮退してしまうことが
分かりました。
※
replication_mode = true
replication_strict = true
load_balance_mode = false
replication_stop_on_mismatch = true
たぶん、下記のような状況なのではないかと想像しました。
trans.1 trans.2
primary secondary primary secondary
: ;
insert :
: select
: select
insert
↑データ件数不一致で縮退!
// 上の insert はもちろん実際には insert/commit です。
insert と select は互いに競合しないので、strict モードであったとしてもタ
イミング次第で上のような状況が起こりうる気がします。縮退時エラーメッセー
ジの kind も 'C'(CommandComplete) と 'D'(DataRow) です。
そこで、データ件数を変化させうる insert/update/delete を含むトランザク
ション全てで、対象テーブルの ACCESS EXCLUSIVE ロックを取得するようにして
みました。僕の理解では、strict モードにおいては、まず primary 側 lock
table、secondary 側 lock table が指示され (この時点で select もブロック
される)、その後 primary 側 insert、secondary 側 insert、primary 側
commit、secondary 側 commit がそれぞれ厳密な順序で実行されると考え、これ
で解決、と思ったのですが…。
その後、再び insert/select 入り乱れるテストを実行してみると、やはり縮退
が発生してしまいました。
なお、pgpool を DEBUG モードにして厳密な動作を確認しようとしてみました
が、DEBUG モードだとなかなか縮退させられず、今のところデータは取れていま
せん。
上記僕の想定はどこがおかしいのでしょうか?上記以外にもデータ件数不一致を
引き起こす要因があったりするのでしょうか?
***
上記のような現象が起こるのは絶妙なタイミング時に限ったことなので、例えば
普段は load_balance_mode = true とか replication_stop_on_mismatch =
false で運用すれば良いじゃないか、というご意見もあるかもしれません。
ただ例えば、「まるごと!PostgreSQL」で石井さんのご紹介されている、フロン
ト側の pgpool の動作するサーバを複数用意したような構成においては、何らか
の原因で1つの pgpool が縮退してしまった場合、他の pgpool はデータ件数不
一致という形でしかそのことを知るすべがありません (もちろん、pgpool の外
側に「ログ監視→他の pgpool を明示的に switch」といった動作を行う監視プロ
グラムを作る、ということは可能ですが…)。
なかなか難しいですね。
--
◇ 加澤恒央 Tsunehisa KAZAWA
◇ ◇ mailto:kazawa @ ca2.so-net.ne.jp
◇ http://www.digitune.org/
pgsql-jp メーリングリストの案内