web-dev-qa-db-ja.com

HDDクラッシュ後にPostgreSQLサーバーを起動するとFAILED状態になります

Fedora 15とPostgreSQL 9.1.4を併用しています。 Fedoraは最近クラッシュしました：

PostgreSQLサーバーを起動する試み：

service postgresql-9.1 start

与える

Starting postgresql-9.1 (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                       [FAILED]

ただし、システムの再起動後に初めてサーバーを起動するとサーバーは正常に起動します。
しかし、psqlを使用しようとすると、次のエラーが発生します。

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

.s.PGSQL.5432ファイルがシステムのどこにも存在しません。 locate .s.PGSQL.5432は何も出力しません。

システムログにはこれがあります：

Aug 14 17:31:58 localhost systemd[1]: postgresql-9.1.service: control process exited, code=exited status=1
Aug 14 17:31:58 localhost systemd[1]: Unit postgresql-9.1.service entered failed state.

あ

systemctl status postgresql-9.1.service

与える

postgresql-9.1.service - SYSV: PostgreSQL database server.
          Loaded: loaded (/etc/rc.d/init.d/postgresql-9.1)
      Active: failed since Tue, 14 Aug 2012 17:31:58 +0530; 58s ago
     Process: 2811 ExecStop=/etc/rc.d/init.d/postgresql-9.1 stop (code=exited, status=1/FAILURE)
     Process: 12423 ExecStart=/etc/rc.d/init.d/postgresql-9.1 start (code=exited, status=1/FAILURE)
    Main PID: 2551 (code=exited, status=1/FAILURE)
      CGroup: name=systemd:/system/postgresql-9.1.service

私はfsyncのデフォルト設定を変更していなかったので、それはonに設定されたと思います。 HDDを使用しています。 HDDがクラッシュしました。

HDDクラッシュ

HDDのクラッシュにより、GUIベースではなく、プロンプトで手動fsckが実行されました。ガジリオンのiノードなどを修復します。その後、システムを再起動し、 Ctrl+Alt+Delete。

PostgreSQLのログはこれを持っています：

LOG:  database system was interrupted; last known up at 2012-08-14 17:31:57 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/41A4E58
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13016) exited with exit code 1
LOG:  aborting startup due to startup process failure

更新

/var/lib/pgsqlディレクトリのファイルシステムレベルのコピーを取得して./pg_resetxlog -f /var/lib/pgsql/9.1/data/を実行し、その結果xlog -f /var/lib/pgsql/9.1/data/を実行した後でサーバーを起動しようとすると、次のようになります。

LOG:  database system was interrupted; last known up at 2012-08-14 18:46:36 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/6000078
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13766) exited with exit code 1
LOG:  aborting startup due to startup process failure
linuxpostgresql
10
ThinkingMonkey

実際の答えは、PostgreSQLログの/var/lib/pgsql/data/pg_logにあります。

ただし、アクションを実行する前に：データに価値がある場合は、修復を試みる前にデータベースのファイルシステムレベルのコピーを作成することが重要です。 http://wiki.postgresql.org/wiki/Corruption を参照してください。データディレクトリ全体をコピーする必要があります。 Fedoraでは、デフォルトで/var/lib/pgsql/dataですが、それがインストールに適していることを確認してください。

あなたが投稿したログに基づいて、確かにある程度のデータベースの破損があります。データベースが存在するストレージ（ハードドライブまたはファイルシステム）が破損している可能性があります。今すぐコピーを取り、それを別のハードドライブまたはシステムに置く。

データディレクトリの完全なファイルシステムレベルのコピーを作成した後にのみ、破損したトランザクションログをクリアしてデータベースを起動するために pg_resetxlog を使用してみてください。起動しても破損している可能性が高いです。 pg_dumpしてから再度initdbして、ダンプを新しいインスタンスに復元する必要があります。

それでもpg_resetxlogを実行しても起動できない場合は、resetxlogの後に起動試行の更新ログを投稿してください。次のコマンドを使用して、スタンドアロンモードでPgを起動する必要がある場合があります。

Sudo -u postgres postgres --single -D /var/lib/pgsql/data -P -f i postgres

それが機能する場合は、backend>プロンプトが表示されます。最後の「postgres」を接続先のDBの名前に置き換えてから、再試行してください。テーブルからデータをSELECT、COPYできるはずです。

それが機能しない場合、つまりスタンドアロンのバックエンドを開始できない場合は、バックアップから復元する時期です。これを読んでいる誰かが同じ立場にいる場合は、 経験豊富なPostgreSQLコンサルタントに連絡してください がデータベースからデータを回復できるかどうかを確認してください。彼らの時間と専門知識を支払う準備をしてください。

ファイルシステムが破損している可能性があります

PostgreSQLインストールの損傷の重大度は、ファイルシステム全体がおそらく損傷していることを示しています。バックアップからシステム全体を復元するか、システムを再インストールすることを検討してください。

私はこのファイルシステムを信頼しません。fsckまたはno fsck。

ドライブのスマートテスト

SmartmontoolsのSMARTを使用して、ハードドライブでsmartctlチェックを実行することもお勧めします。 /dev/hdaだとすると、smartctl -d ata -a /dev/sda | lessになります。失敗したヘルステストuncorrectable_sectors、高い読み取りエラー率、2または3を超えるreallocated_sector_count、またはゼロ以外のcurrent_pending_sectorを探します。 smartctl -d ata -t long /dev/sdaを実行して、HDDで非破壊的なセルフテストを実行します。システムの通常の機能を妨げることはありません。推定時間が経過したら、再度smartctl -d ata /dev/sdaを実行し、セルフテストログを調べて、合格したかどうかを確認します。

完璧とは言えないものがある場合は、ドライブを交換してください。

今後、ドライブ障害の早期警告のために、smartdを介してこのテストを自動化することを検討してください。

（この投稿の内容は、質問の更新によって廃止されました。同様の問題をトラブルシューティングしている場合は、この回答の編集履歴を確認してください）。

15
Craig Ringer