[pgsql-jp: 41808] Re: PostgreSQL9.3でのclogファイル削除

[TAKATSUKA Haruka]

高塚と申します。

原因や仕組みについては割愛させていただきますが、いくつかコメントいたします。

バージョン 9.3.x  の x はいくつでしょうか？ 9.3.0 ということでしょうか。
http://www.sraoss.co.jp/technology/postgresql/9.3.2/ の 1番の障害に
する可能性があり、また、実行トランザクション数が2^31を超えていないなら、
まずは、
　・全データベースを VACUUM FREEZE する
を試みるべきです。

また、上記で直らないとして、当面対策としては、
　・手で clogファイルを作る
で良いでしょう。

0x00 埋めだと未コミットの意味で、コミット済は 0x55 ('U') 埋め。いずれに
しても正しくない SELECT結果が生じる可能性は残りますが、とりあえず
ERROR になることは防げます。

機会をみて以下は行いたいところです。
　・PostgreSQL 9.3.x 最新へのバージョンアップ

pg_resetxlog が効果的であるか疑問です。不正なデータ状態を追放するために
行うべきは、以下であろうかと思います。
　・ダンプ、停止、$PGDATA退避、initdb、リストア、レプリケーション再構成



On Fri, 7 Aug 2015 09:28:05 +0900
Keiichi Sadanaga <ksfore ＠ gmail.com> wrote:

> 貞永と申します。
> 
> PostgreSQL9.3, pgpool-ii 3.3.1を使用したLB+SRの環境にて、
> 
> ERROR: could not access status of transaction xxxxxxxx
> Detail: Could not open file "pg_clog/xxxx": No such file or directory
> (一部マスク)
> 
> というエラーが特定のテーブルへのselect時に発生しています。
> 調査すると、削除されたclogファイルは、clogの中でも一番古いファイルでした。
> DB全体は稼働しており、他への影響は今のところないようです。
> 
> サイトを探してみると
> ddコマンドで0埋めたファイルを削除されたファイルとして作成すると回復するというのがいくつか見つかりました。
> (ex. http://www.postgresql.org/message-id/3756.1074890527@sss.pgh.pa.us)
> 
> 他には、pg_resetxlogで回復するというのもありますが、DBの再起動が必要なので、躊躇しています。
> 
> Postgresqlのバグで、トランザクション数が2^31を超えると起こりうるというのもありましたが、そこまで行っていませんでした。
> 
> 今回のようなエラーが特定のテーブルへのselect時に発生する場合の対応は、上記のddで解消するものでしょうか。
> 最終的にはpg_resetxlogをすれば解消するものでしょうか。
> 本番環境なので、あまり試行はできないのですが、なるべく停止をせずに解消したいと思っています
> 
> また、clogファイルが削除されるというのは、vacuumでの処理に伴うものでしょうか？（人手では削除していません）
> 
> clogファイルがどのようなタイミングでどのような条件で削除されるのでしょうか。
> 
> また、selectする際に過去のトランザクションがあるclogを見に行くのが、仕組み的にわかっていないですが、vacuumがされていない為でしょうか。autovacuumは有効になっています。
> 
> 障害への対応方法と、障害の発生原因と考えられるものについて、ご教授していただきますようお願いいたします。


______________________________________________________________________
 日本PostgreSQLユーザ会  高塚 遙  http://www.postgresql.jp