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

[kasaharatt ＠ nttdata.co.jp]

笠原と申します。

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 ＠ ml.postgresql.jp
> [mailto:pgsql-jp-bounces ＠ ml.postgresql.jp] 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 ＠ metrosystems.co.jp
>  Tel : 03-5951-1219
>  Fax : 03-5951-2929