2012年5月24日

[pgsql-jp: 41113] Re:unloggedなテーブルのスレーブでの参照

笠原と申します。

9.1.3で色々と試してみました。

> pg_dump/pg_dumpall については --no-unlogged-table-data オプションを指
> 定することでエラーを回避できるかもしれません。
> http://www.postgresql.jp/document/pg912doc/html/app-pgdump.html
これで回避できそうです。


$ psql -p5432 ★ マスタ
=# CREATE UNLOGGED TABLE test1 (id int primary key);
=# \q

$ psql -p5433 ★スタンバイ
=# SELECT * FROM test1;
ERROR: cannot access temporary or unlogged relations during recovery
=# \q

$ pg_dumpall -p5433 > /tmp/dump.txt ★NG
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: could not open file "base/12780/16387": No such file or directory
pg_dump: The command was: COPY public.test1 (id) TO stdout;
pg_dumpall: pg_dump failed on database "postgres", exiting
$ pg_dumpall -p5433 --no-unlogged-table-data > /tmp/dump.txt ★OK


> CREATE UNLOGGED TABLE 直後はスレーブで検索などをしてもエラーにならず、
> マスタで TRUNCATE するとそれ以降エラーが出るようになる、ということであれ
> ばこのバグに引っかかっているのだと思います。
僕もそう思います。

$ psql -p5432
=# CREATE UNLOGGED TABLE test2 (id int primary key);
=# INSERT INTO test2 VALUES (1);
=# TRUNCATE test2;
=# \q

$ psql -p5433
=# SELECT * FROM test2;
ERROR: cannot access temporary or unlogged relations during recovery
=# \q
$ pg_ctl -D base/ss promote ★昇格
server promoting
$ psql -p5433
=# SELECT * FROM test2; ★NG
ERROR: could not open file "base/12780/16400": No such file or directory

根本対処は9.1.4を待つしかないですかね。
それまでは花田さんの対処方法が良いかと思います。

--
笠原 辰仁


> -----Original Message-----
> From: pgsql-jp-bounces@xxxxx
> [mailto:pgsql-jp-bounces@xxxxx] On Behalf Of 花田 茂
> Sent: Thursday, May 24, 2012 4:57 PM
> To: PostgreSQL Japanese Mailing List
> Subject: [pgsql-jp: 41112] Re: unloggedなテーブルのスレーブでの参照
>
> 花田です。
> レプリケーション環境が手元にないので確実な回答ではありませんが…
>
> (2012/05/24 15:41), 松崎 学 wrote:
> > 松崎ともうします。お世話になります。
> >
> > 9.1.2を同期レプリケーションモードで構成しています。
> >
> > ワークテーブルとして使っているunloggedオプション付きのテーブルがあ
> るのですが、
> > unloggedを付けていると、以下のような場合そのテーブルを参照した時にエ
> ラーになってしまいます。
> >
> > 1. スレーブ側でダンプを取得する時
> > → pg_dump: サーバのエラーメッセージ: ERROR: could not open file
> > "pg_tblspc/16384/PG_9.1_201105231/89589/270288": No such file or
> > directory
>
> pg_dump/pg_dumpall については --no-unlogged-table-data オプションを指
> 定
> することでエラーを回避できるかもしれません。
> http://www.postgresql.jp/document/pg912doc/html/app-pgdump.html
>
> > --no-unlogged-table-data
> > ログを取らないテーブルの内容をダンプしません。 このオプショ
> > ンはテーブル定義(スキーマ)をダンプするかどうかには影響しま
> > せん。 そのテーブルデータのダンプを抑制するだけです。
>
> ただし、根本的には UNLOGGED テーブルを構成するデータファイルが存在しな
> い、ということが原因のようなので、この対処はあくまで急場しのぎです。
>
> > 2. マスタに障害が発生してスレーブがマスタに昇格後、そのテーブルを
> DELETEやSELECTする時。
> > → エラーメッセージはダンプ取得時と同じです。テーブルをdropして
> createし直すとエラーは出なくなります。
>
> このエラーが出始める前に、ひょっとしたらマスターで UNLOGGED 指定したワ
> ー
> クテーブルを TRUNCATE しているでしょうか?最近(五月に入ってから)報告
> さ
> れたバグに「UNLOGGED テーブルを TRUNCATE するとデータファイルが消える」
> というものがありました。
>
> http://archives.postgresql.org/pgsql-bugs/2012-05/msg00049.php
>
> CREATE UNLOGGED TABLE 直後はスレーブで検索などをしてもエラーにならず、
> マ
> スタで TRUNCATE するとそれ以降エラーが出るようになる、ということであれ
> ば
> このバグに引っかかっているのだと思います。
>
> すでに修正は済んでいるので、次のマイナーリリース(9.1.4)にアップグレード
> すれば直ると思いますが、それまでは TRUNCATE ではなく DROP/CREATE や
> DELETEに置き換えるといった対処が必要そうです。
>
> --
> 株式会社メトロシステムズ
> 花田 茂
> Mail : hanada@xxxxx
> Tel : 03-5951-1219
> Fax : 03-5951-2929

投稿者 xml-rpc : 2012年5月24日 17:22
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/110577
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。