« [postgresql] postgresqlでハイアベイラビリティ?とかやってみる | メイン | レンタルサーバーと自宅サーバー、電気代は結構高い »

[postgresql] pgpoolでinsert_lock=trueがありえない場合(2008/06/18)

 昨日に引き続きpostgresqlの話。最近までpostgresqlの呼び名が分からず、ポストグレ・エス・キュー・エルだと思っておったのだが、違ったようだ。ポスグレと呼んでいたので会話では通じていたが。そんなことはさておき、pgpoolのレプリケーションモードを使ったときの話をしよう。

 「レプリケーションして、負荷分散とかできたら素敵」という甘い幻想のもとに今回の話をすすめよう。ちなみに、「postgresqlは商用DB並だが、周辺ツールがアホすぎる。」というのはどこかのDB専門家が言ったとか言わないとか。

 レプリケーションする場合、pgpoolはあくまでsqlベースのコピーというか複製をDB-A、DB-Bに投げる。そのため、serial型で自動で採番する方式にしているテーブルにinsertする際に問題が起こる。DB-A,DB-B両方で全く同じnextval値が得られる保証が無いのだ。これは致命的。

 そこで、テーブルをロックしようという話になる。テーブルをロックしてしまえば、ロック中にほかのinsertは割り込めないので間違いなく同じ値がinsertされるのだ!!おおおぉ!やった!

 ただし、これにはあたりまえだが副作用がある。何しろロックである。ロックというこは、ほかの処理がinsertしてきたら、先の処理が終わるまで待たされるのだ。不特定多数の人が使うような、たとえばウェブアプリケーションとか、だと悲惨なことになる。同じinsert処理が走る操作をされると、処理時間が平均で[insertにかかる時間]x[同時アクセス数]が処理にかかる時間になってしまうのだ。うひゃ。

 インサートロックの設定は、pgpoolの設定ファイルでinsert_lock=trueにするとできるのだが基本的にはそれは無しの方針で。アプリ側を改良して、テーブルロックを避けられるように実装するか(つまり可能な限りシーケンスを使わない。もっと言うとアクセスが集中する処理にはシーケンスを使わない。)、pgpoolでレプリケーションするのをやめるか、かな

 やはり「postgresqlの周辺ツールで夢を見るのはやめよう!」ということなのかもしれない。結論:postgresqlのデフォルト構成でがんばれるところまでやるべき!

トラックバック

この記事のトラックバックURL:
https://www.typepad.com/services/trackback/6a00d8341c2e2e53ef00e5535bc1948833

[postgresql] pgpoolでinsert_lock=trueがありえない場合を参照しているブログ:

コメント

この記事へのコメントは終了しました。