[pgsql-jp: 41949] Pgpool利用環境でCOPYfrom実行エラー時にPgpoolがダウンする

[FASYS）小川 智康]

お世話になっております。小川と申します。
またもや古いバージョンの環境で恐縮ですが、
アドバイスいただければ幸いです。

＜使用環境＞
・pgpool2-2.3.3
　　レプリケーションモード
・postgres 8.0.4×2サーバー

＜状況＞
先日、特定のバッチを起動するとpgpoolがダウンする事象が
発生いたしました。
1日に2度ダウンしましたが、いずれも同一バッチ起動時に発生しているため、
このバッチ処理がトリガーで間違いないと認識しております。

バッチ処理は以下のような形で
pgpool経由でcopy to,copy fromを実行しております。

psql -p PPPP -d DDDD<<EOD
        \copy TTTT to BACKUP.csv using delimiters ',' with null as ''
EOD

psql -p PPPP -d DDDD<<EOD
        \copy TTTT from INSERT.csv using delimiters ',' with null as ''
EOD

今回は運用ミスにより
上記処理にて使用している「INSERT.csv」ファイルに
登録済みデータを含めた形にしていたため、
バッチ実行時に以下のような一意制約エラーが発生してしまいました。

ERROR:  duplicate key violates unique constraint "TTTT_pkey"

テーブルは列が5つあるだけで、1レコードあたりのデータは
CSVで記述してもせいぜ80〜100バイト程度で、
今回のエラーはCSVファイルの41行目に発生しておりました。
CSVファイル全体では350行程度になります。


しかし検証環境を構築して同じデータ状態で同じバッチ処理を実行し、
同じエラーを発生させましたが、
検証環境ではpgpoolのダウンは発生いたしませんでした。


本番環境と検証環境の差異といえば、
サーバスペックが検証環境の方が高性能であることと、
本番環境は定期的なVacuum処理が行われていないため、
baseディレクトリ内の容量がそれぞれ約7.5GB、約9.3GBと差があること、
くらいになります。
（レプリケーションでデータが同一なのにディレクトリ容量が異なるのは、
　それだけゴミが蓄積されているものと認識しております。
　この認識に間違いがありましたらご指定いただけると幸いです）

そこで、今回はとりあえずVacuum処理をして
ゴミを取り除くことを対策として検討しておりますが、
果たしてこれだけで今回の現象が回避できるものなのか、不安でおります。


pgpoolとcopy fromの相性が悪いという噂も聞いていたのですが、
調べた限りVer2.3.3では解消済みではないかと思われます。
しかしながら、copy fromは使用しない方がよろしいのでしょうか。

あるいは、冗長化している2台のDBのゴミの量に極端な差がある場合、
pgpoolがダウンするリスクが高くなるものなので、
やはりvacuumすることで回避できそうなものとなるのでしょうか。

あいまいな質問で申し訳ございませんがよろしくお願いいたします。




=============================================
株式会社富士通アドバンストシステムズ [略称：FASYS]
 第一システム事業部　第一システム部
  小川　智康　（Ogawa　Tomoyasu）

  〒464-0075
  名古屋市千種区内山3-29-10 千種AMビル6階
  TEL :052-735-3777／FAX :052-745-1377
  E-Mail:ogawa.tomoyasu ＠ jp.fujitsu.com

 河合塾常駐席
  TEL :052-735-1758／FAX :052-735-1790
  内線:*-53-1758
  E-Mail:tomoyasu.ogawa ＠ keinet.ne.jp
=============================================