[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 メーリングリストの案内