[pgsql-jp: 36205] Re: pg_clogディレクトリ内のログが参照できずPANIC
松本 貴臣
matsumoto_takaomi @ nextcom.co.jp
2005年 10月 19日 (水) 16:08:37 JST
お世話になっております。
松本です。
その後のご報告が遅くなり、申し訳ございません。
谷田さん、ありがとうございました。
谷田さんにアドバイス頂いた対応を実施しました。
(復旧しかと思われましたが、事情により、HWチェックができない為、
数日後再発しました。)
# cd /home/postgres/data/pg_clog
# dd bs=8k count=32 </dev/zero >> ./001B
その後、念の為、以下のvacuumdbを実行したところ、
再度、PANICが発生しました。
# vacuumdb -a -z -U postgres
これは、-aオプションを付けたことにより、本番DBへのvacuumを実行する前に、
どうもパフォーマンステスト用で作成したbenchというDBのvacuumが
終わったタイミングで、コミットログ(001B)が削除された感じでした。
そこで、再度、ddコマンドにて001Bを作成し、以下のように本番DBを指定した形
で実行したところ、すんなりvacuumが終わり、後は-aをつけてもうまく
通るようになりました。
# vacuumdb -d testdb -z -U postgres
谷田さんよりご指摘頂いた、memtest86を実行する場合、サービスを停止状態で
実行しなければならないかと思い、対応できておりません・・・。
今回のシステムでは、代替するサーバがない為、memtest86を実施中は、
サービスを止めなければならないという事情がございます。
その為、memtest86の実施はできておりません・・・・。
そのまま様子を見ていたところ、数日後また同様のPANICが
発生してしまいました。
【ご質問】
* やはり何かしらのハードウェアトラブルが発生しているのでしょうか。
Vacuumを実行しても発生したり、しなかったりとなるという状態でして、
本当にハードウェアが要因なのか疑問を感じてしまっております。
(すいません、初歩的な質問になってしまっているかもしれませんが・・)
* ハードの検証となると、以下のツールを使うと考えておりますが、
認識に問題はないでしょうか。
1. メモリ:memtest86
2. HDD :fsck
* 以下の形で処理を実行しています。
1. select * from pgstattuple('tbl')
2. vacuumdb -a -U postgres -z
3. select * from pgstattuple('tbl')
1のpgstattupleは問題なく通るのですが、3のpgstattupleでコケます。
vacuumdbで、removingしたclogが原因かとは思いますが、
pgstattupleが何かやっているという事は、やなり考えられないで
しょうか・・・・。
* この事象が発生したのは、postgresql.confに以下の設定を付与してから、
(たまたまかもしれませんが)発生しています。
stats_start_collector = true
stats_reset_on_server_start = true
stats_block_level = true
これが原因という事は考えられないでしょうか。
以上、よろしくお願いいたします。
On 2005/10/14 11:56, TANIDA Yutaka様の書かれたメール:
> 谷田です。
>
> On Fri, 14 Oct 2005 08:45:59 +0900
> 松本 貴臣 <matsumoto_takaomi @ nextcom.co.jp> wrote:
>
>
>>readhat+java+postgres7.3.6を採用し、システムを構築しております。
>>以下のようなPANICが頻発し、原因の究明にあたっておりますが、
>>行き詰まっております。
>>皆様のお知恵を頂戴できればと思い、ご連絡差し上げた次第でございます。
>>
>>[事象]
>>以下のようなログが発生し、コネクションがクローズされる。
>>
>>=========================================================
>>postgres[28659]: [3] PANIC: open of /home/postgres/data/pg_clog/001B
>>failed: そのようなファイルやディレクトリはありません
>
> (snip)
>
>
>>[ご質問]
>> * これはDBが破損した状態で復旧はできないのでしょうか。
>
>
> すでに無い pg_clog以下のファイル、あるいは明らかに未来のものを参照してい
> るケースというのは、メモリエラー、あるいはディスクエラーにより既存の
> xmin,xmax等のxid型システムカラムが破壊された(ために、間違ったpg_clog以
> 下のファイルを参照してしまう)と考えてほぼ間違いないです。
>
> 復旧のためには、ddとかで001Bファイルを256KBサイズで適当に作ってやれば、
> ひとまず読み込むことができるでしょう。その後はmemtest86を1日程度やって
> みてメモリにエラーが無いかどうかとか、ディスクとか、そういうトラブルを洗
> うことをお勧めします。
>
>
>> * pg_resetxlogを使えるかもと思ったのですが、
>> 「最後の手段」的な記述があったため、躊躇っております。
>> 他にリスクの低い方法はございませんでしょうか。
>
>
> 残念ながら、このケースを復活するためにはpg_resetxlogでは不十分です。
>
--
/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
ネクストコム株式会社 大阪支店 技術三課
松本 貴臣 (TEL : 06-6205-3017)
E-mail : matsumoto_takaomi @ nextcom.co.jp
pgsql-jp メーリングリストの案内