pg_resetxlog

Name

pg_resetxlog -- ログ先行書き込みおよび pg_control の内容の初期化

Synopsis

pg_resetxlog [ -f ] [ -n ] [ -o oid ] [ -x xid ] [ -l fileid,seg ] datadir

説明

pg_resetxlog は、先行書き込みログを消去し、さらにオプションで pg_control ファイル内のフィールドの一部を初期化します。 この機能は、これらのファイルが破壊された場合に必要になることがあります。 そのような場合、この機能は、サーバを起動できない場合の最後の手段としてのみ使用するようにしてください。

このコマンドを実行するとサーバを開始できるようになるはずです。ただし、不完全にコミットされたトランザクションが原因でデータベースのデータに矛盾が起こる可能性があることに注意してください。 データを直ちにダンプし、initdb を実行し、リロードする必要があります。 リロード後、矛盾がないかチェックし必要に応じて修復を行なってください。

このユーティリティの実行には datadir への読み込み/書き込みアクセス権限が必要となるため、サーバをインストールしたユーザのみが実行できます。 安全のため、データディレクトリをコマンドラインで指定する必要があります。pg_resetxlog は、環境変数 PGDATA を使用しません。

pg_resetxlogpg_control に対する有効なデータを判別できない場合には、-f (強制) スイッチを指定して強制的に処理を進めることができます。 その場合、欠落したデータには代用できる無難な値が使用されます。 ほとんどフィールドは適切であると思われますが、次の OID、次のトランザクション ID、WAL 開始アドレスおよびデータベースロケールフィールドについては、手動の操作が必要な場合があります。 最初の 3 つについては下記で説明するスイッチを使用して設定することができます。pg_resetxlog 自身の環境がロケールフィールドを想定するための基礎となるので LANG などの値が initdb が実行された環境と一致するよう注意してください。 これらのフィールド用の正しい値をすべて決定できない場合にも、-f を使用することができますが、回復したデータベースは通常よりさらに注意深く検査する必要があります。必ず、直ちにダンプおよびリロードを行なってください。 決して、ダンプを行なう前にデータベースでデータ変更などの操作を行なってはなりません。これを行なうと、破損状態がさらに悪化します。

-o-x、および -l の各スイッチを使用して、次の OID、次のトランザクション ID、そして WAL 開始アドレスの値を手動で設定することができます。 この操作は、pg_resetxlogpg_control を読み込むことによって適切な値を判別できない場合にのみ必要です。 次のトランザクション ID のための安全な値を決定するには、以下のようにします。まず、$PGDATA/pg_clog 内で最も大きなファイル名の値を見つけ、それに 1 を加え、1048576 で乗算します。ファイル名は、16 進数です。 通常、スイッチの値も 16 進数で指定するのが簡単な方法です。 例えば、0011pg_clog で最も大きなエントリであれば、-x 0x1200000 となります (後のゼロ 5 つにより適切な乗数となります)。 WAL 開始アドレスは、$PGDATA/pg_xlog に現在存在するファイルのどの番号よりも大きくならなければなりません。 これらも 16 進数で、2 つの部分に分かれます。 例えば、pg_xlog 内で最大のエントリが 000000FF0000003A である場合は、-l 0xFF,0x3B となります。 データベース内で最大の OID を越える、次の OID を決定するには、このような簡単な方法はありません。しかし幸い、次の OID が正しく設定されているかどうかは、それほど重要ではありません。

-n (操作なし) スイッチは、pg_resetxlog に対し pg_control から再構築された値を出力するよう指示し、何も変更せずに終了します。 これは主にデバッグと目的としたツールですが、pg_resetxlog を実際に進める前の検査としても有用な場合があります。

注釈

このコマンドは、postmaster の稼動中に使用してはなりません。pg_resetxlog は、datadir に postmaster ロックファイルを見つけると始動しません。 postmaster がクラッシュした際にロックファイルがそのまま残される場合があります。その場合は、ロックファイルを削除して pg_resetxlog を実行することができます。 ただしこれを行う前に、まだ活動中の postmaster、あるいはバックエンドのサーバプロセスが一切ないことを確認してください。