[pgsql-jp: 33470] Re: pgpoolでsecondary

Tatsuo Ishii t-ishii @ sra.co.jp
2004年 7月 2日 (金) 12:05:51 JST


石井です.

> 西尾です。
> 
> > 確認ですが,7.5.3ではなくて,7.4.3ですよね?まだ7.5はリリースされてま
> > せんから...
> 
> すみません、間違えてました。
> 正確には、
>  PostgreSQL 7.3.6 on sparc-sun-solaris2.8, compiled by GCC gcc (GCC) 3.3.2
> です。
> 
> > もし,複数のセッションを同時に走らせ,それぞれ削除,更新をしていたとす
> > ると,これは起こり得ます.というのも,pgpoolでは同じセッションの中では
> > (strict modeならば)必ずmasterのクエリが実行されてからsecondaryのクエリ
> > が実行されることが保証されているものの,異なるセッションの間ではそうい
> > う保証はないからです.
> 
> データベースの不整合の再現に手間取っており返事が遅くなりました。
> で、不整合の原因ですが、データ登録時にチェックとしてpsqlの操作を行っていた
> 事が原因のようです。やっていたのはSELECTだけですが、こういうことが起こるん
> ですね。
> 
> 単純に非公開のサーバで、ブラウザからCSVをアップロードしてファイルの内容を
> データベースに登録しているだけなので複数のセッションが同時に走っているとは
> 考えにくいですし。
> 
> それで、不整合のある状態でパッチを当てたpgpoolを使用してみましたが、状況は
> 前回と変わりませんでした。

あのパッチは7.4のルートにだけ変更が行われています.ですから,実際には
7.3.6を使っているんだったら状況は変わりません.

> そのときのpgpoolのログは以下の通りです。
> 
> 
> DEBUG: pid 438: read kind from backend pending data D len: 79 po: 943
> DEBUG: pid 438: AsciiRow: len:3 data: 00
> DEBUG: pid 438: AsciiRow: len:10 data: 2003-07-1
> DEBUG: pid 438: AsciiRow: len:6 data: 20913
> log: pid 438: AsciiRow: 3 th field size does not match between master(5) and secondary(7)
> DEBUG: pid 438: AsciiRow: len:1 data:
> log: pid 438: AsciiRow: 6 th field size does not match between master(20) and secondary(5)
> DEBUG: pid 438: AsciiRow: len:16 data: バラ 1000g×
> log: pid 438: AsciiRow: 7 th field size does not match between master(9) and secondary(6)
> DEBUG: pid 438: AsciiRow: len:5 data: 187.
> log: pid 438: AsciiRow: 8 th field size does not match between master(6) and secondary(8)
> DEBUG: pid 438: AsciiRow: len:2 data:
> log: pid 438: AsciiRow: 9 th field size does not match between master(8) and secondary(12)
> DEBUG: pid 438: AsciiRow: len:4 data: T00
> log: pid 438: AsciiRow: 10 th field size does not match between master(12) and secondary(5)
> DEBUG: pid 438: AsciiRow: len:8 data: 池田医
> 煙og: pid 438: AsciiRow: 11 th field size does not match between master(11) and secondary(22)
> DEBUG: pid 438: AsciiRow: len:7 data: 1406.2

良く見るとわかりますが,ここまではlogとかDEBUGとかは出力されていますが,
ERRORはないので,処理は継続されているはずです.logがずらずら出てくるの
は,前のメールで説明したように,行の並びが物理的にmasterとsecondaryで
異なっているためであると思われます.つまり,ここまでは想定の範囲内です.

> ERROR: pid 438: pool_process_query: kind does not match between backends master() secondary(D)

問題はここですね.ここではsecondaryは"D",すなわち行データを引き続き送
ろうとしているのに,master側ではもうデータがないことになっています.つ
まり,masterとsecondaryの検索件数が一致していないことになります.こう
いうことは普通は起きないはずなのですが,何か想定外の現象が起きているよ
うに思えます.できれば実行したSQL文と実データを見せてもらえれば何か分
かると思うのですが.あるいは同じような現象を再現できる方法を教えていた
だけるとか.
--
Tatsuo Ishii



pgsql-jp メーリングリストの案内