2012年5月24日

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

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

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

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

教えて頂いたように、以下の方法で9.1.4リリースまで凌ごうとおもいます。
・対象のテーブルを再作成。

・ワークテーブルのtruncateをdeleteに変更。
・pg_dumpに --no-unlogged-table-data オプションを付ける。

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

2012年5月24日 17:22 <kasaharatt@xxxxx>:
> 笠原と申します。
>
> 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

--
松崎 学 <matsumana@xxxxx>


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




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