[pgsql-jp: 33613] Re: pgpool 2.0.2 報告

Tatsuo Ishii t-ishii @ sra.co.jp
2004年 7月 10日 (土) 21:04:41 JST


石井です.

> > o 同じ名前のテーブルなのに,構造が異なる
> > o 同じ名前のテーブルなのに,行数が異なる
> > 
> > もアウトです.
> 
> カラム数とタプル数のチェックのみでしょうか?

どういうチェックを行っているかお話しした方が早そうなので,解説します.

SELECTをバックエンドで実行すると,その結果が以下のようにして返ってきま
す.

1) まず列の数,型名に関する情報が送られる

   このときpgpoolは,V3プロトコル(7.4以降)では,単に情報パケットを長さ
   分読んでフロントエンドに転送するだけなので,問題ない.しかし,V2プ
   ロトコル(7.3以前)では,列の数分だけ1個1個列情報を読まなければならな
   いので,列の数がマスタとセカンダリで食い違うとエラーになってしまい
   ます.

2) 次に行の分だけ情報パケットが送られてくる

   V2プロトコルでは,このパケットの頭に各列の値がNULLかどうかのマップ
   を持っています.列の数が違うと,マップ領域の大きさの違いのためにこ
   こでエラーになる可能性があります.次に各列の値が出現します.ここで
   も列の数が異なるとエラーになる可能性があります.

   一方,V3プロトコルでは,パケットの頭の長さ分を処理すれば良いだけな
   ので,こういう問題が起きません.

3) 行数分だけ情報パケットの送信が終わると,完了を示すパケットが送信さ
   れる

   もしマスタとセカンダリの行数が異なると,片方では行の情報が来るのに,
   一方では完了を示すパケットが来るため,エラーになります.

> デフォルト値や制約も「構造」という言葉に含みますか?

上記により,ことSELECTに関しては問題になりません.ただ,psqlの\dtなど
では,psqlの内部で発行したSELECT結果の行数が異なるため,エラーになりま
す.

> > それと,シーケンスやSERIAL型も要注意です.PGClusterと違って明示的にシー
> > ケンスを同期させる機構を持たないpgpoolでは,たとえば複数接続から同時に
> > SERIAL型を使っている同じテーブルにデータを追加すると,シーケンスの値が
> > ずれることがあります.
> 
> この場合、SELECT 時に、master と secondary の値が違う、とい
> うことで縮退運転されてしまいますか?

pgpoolでは,各行の値の中身までは見ていないのでそれ自体はエラーになり
ません.ただし,アプリケーションでシーケンスの値に基づいて発行した
SELECT文の結果行数が異なった結果,エラーになってしまうことがあります.

ちなみに,pgpool 2.0以降では,こうした際に縮退運転するかしないかを選択
できるようになっています.

> master と secondary の値が違えてしまうケースとして、更新・追
> 加時の current_timestamp や random() が 考えられますが、これ
> の対策ってなされてるのでしょうか・・・?(current_timestamp 
> は時計合わせとけって話なんですが)

pgpoolでは何もしていません.

こういった問題はなかなか頭の痛いところですが,解決方法としては以下のよ
うなものが考えられます.

1) current_timestamp や random()を使用せず,アプリケーションの方で値を
   生成してSQL文に埋め込む.ただし,フロントエンドの間で時計がずれてい
   るとcurrent_timestampがずれる可能性はあります.

2) (これは単なるアイデアレベルですが)pgpoolの中にそうした値を生成す
   る機能を入れる.そして値をSELECT文で取得できるようにしておき,それ
   をアプリケーションに使ってもらう.

3) current_timestamp や random()そのものを入れ替える(同じような発想で,
   Slony-Iではシーケンス関数を入れ替えてます).こうした方法が良いか悪
   いかは,議論のあるところだと思いますが.

まあ,今後どうするかはこれからじっくり考えたいと思います.

> pgpool を経由せずに直接 master あるいは secondary に接続し 
> VACUUM する、という意味だと思います。
> コレを良しとするのであれば、照会のみの時は pgpool を経由せず
> に master または secondary に接続することによって照会速度を
> 上げる、という方法もアリですね。

DBの内容を論理的に書き換えない操作であれば,それもありです.
--
Tatsuo Ishii



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