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

[松崎 学]

吉田さん、花田さん、笠原さん

松崎です。お世話になります。

夜間にワークテーブルをクリアするため、truncateしておりました。

教えて頂いたように、以下の方法で9.1.4リリースまで凌ごうとおもいます。
・対象のテーブルを再作成。
・ワークテーブルのtruncateをdeleteに変更。
・pg_dumpに --no-unlogged-table-data オプションを付ける。

今後は本家のMLもチェックしていこうと思います。
ありがとうございました。

2012年5月24日 17:22  <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



-- 
松崎 学 <matsumana ＠ gmail.com>