Ich benutze Fedora 15mit PostgreSQL 9.1.4. Fedora stürzte kürzlich ab, woraufhin:

Ein Versuch, den PostgreSQL-Server zu starten:

service postgresql-9.1 start

gibt

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

Obwohl der Server beginnt in der Regel , wenn ich den Server zum ersten Mal nach dem Neustart des Systems starten .
Ein Verwendungsversuch psqlführt jedoch zu folgendem Fehler:

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.5432Datei ist nirgendwo im System vorhanden. A locate .s.PGSQL.5432gibt nichts aus.

Das Systemprotokoll enthält Folgendes:

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.

EIN

systemctl status postgresql-9.1.service

gibt

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

Ich hatte die Standardeinstellung von fsync nicht geändert, also schätze ich, sie wurde auf eingestellt on. Ich bin auf einer Festplatte. Die Festplatte ist abgestürzt.

Festplattenabsturz

Der Festplattenabsturz führte dazu, dass ein Handbuch fsckauf einer Eingabeaufforderung und nicht auf GUI-Basis ausgeführt wurde. Damit reparierte ich Millionen Inodes usw. Danach startete ich das System mit einem Ctrl+ Alt+ neu Delete.

Das PostgreSQL-Protokoll enthält Folgendes:

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

Aktualisieren

Der Versuch, den Server zu starten, nachdem eine Kopie des /var/lib/pgsqlVerzeichnisses auf Dateisystemebene erstellt und ./pg_resetxlog -f /var/lib/pgsql/9.1/data/mit dem Ergebnis ausgeführt wurde, führt xlog -f /var/lib/pgsql/9.1/data/weiterhin zu folgenden Ergebnissen :

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

Die eigentliche Antwort finden Sie in den PostgreSQL-Protokollen in /var/lib/pgsql/data/pg_log.

Bevor Sie jedoch Maßnahmen ergreifen: Es ist wichtig, dass Sie vor dem Reparaturversuch eine Kopie Ihrer Datenbank auf Dateisystemebene erstellen, wenn Ihre Daten für Sie wertvoll sind . Siehe http://wiki.postgresql.org/wiki/Corruption . Sie müssen das gesamte Datenverzeichnis kopieren. Unter Fedora ist dies /var/lib/pgsql/datastandardmäßig der Fall, aber überprüfen Sie, ob dies für Ihre Installation korrekt ist.

Basierend auf den von Ihnen veröffentlichten Protokollen haben Sie sicherlich einen gewissen Grad an Datenbankbeschädigung. Der Speicher, auf dem sich die Datenbank befindet (Festplatte oder Dateisystem), ist höchstwahrscheinlich beschädigt. Nehmen Sie JETZT eine Kopie und legen Sie sie auf eine andere Festplatte oder ein anderes System .

Versuchen Sie erst, wenn Sie eine vollständige Kopie Ihres Datenverzeichnisses auf Dateisystemebene erstellt haben, mit pg_resetxlog die beschädigten Transaktionsprotokolle zu löschen und Ihre Datenbank zu starten. Selbst wenn es startet, ist es sehr wahrscheinlich, dass es korrupt ist. Sie sollten pg_dumpes dann erneut verwenden initdbund den Speicherauszug in der neuen Instanz wiederherstellen.

Wenn Sie es nach einem immer noch nicht starten können, veröffentlichen Sie pg_resetxlogein aktualisiertes Protokoll des Startversuchs nach dem Zurücksetzen des Protokolls. Möglicherweise müssen Sie Pg im Standalone-Modus starten mit:

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

Wenn dies funktioniert und Sie eine backend>Eingabeaufforderung erhalten, versuchen Sie es erneut, nachdem Sie die letzten "Postgres" durch den Namen der Datenbank ersetzt haben, zu der Sie eine Verbindung herstellen möchten. Sie sollten in der Lage sein SELECT, COPYDaten aus Tabellen usw.

Wenn dies nicht funktioniert, dh Sie können kein eigenständiges Backend starten, ist es wahrscheinlich an der Zeit, Backups wiederherzustellen - da Sie vernünftig genug sind, diese zu haben. Wenn sich jemand anderes in derselben Position befindet, wenden Sie sich an einen erfahrenen PostgreSQL-Berater, um zu erfahren , ob er Daten aus Ihrer Datenbank wiederherstellen kann. Seien Sie bereit, für ihre Zeit und ihr Fachwissen zu bezahlen.

Ihr Dateisystem ist wahrscheinlich beschädigt

Die Schwere des Schadens an der PostgreSQL-Installation lässt darauf schließen, dass Ihr gesamtes Dateisystem wahrscheinlich beschädigt ist. Möglicherweise möchten Sie das gesamte System aus einer Sicherung wiederherstellen oder neu installieren.

Ich würde diesem Dateisystem nicht vertrauen fsckoder nein fsck.

Testen Sie Ihr Laufwerk SMART

Ich empfehle außerdem, dass Sie SMARTmit smartctlSmartmontools eine Überprüfung Ihrer Festplatte durchführen . vorausgesetzt, es /dev/hdawäre das smartctl -d ata -a /dev/sda | less. Suchen Sie nach einem fehlgeschlagenen Zustandstest uncorrectable_sectors, einer hohen Lesefehlerrate, einem neu zugewiesenen Sektor_Zahl von mehr als 2 oder 3 oder einem aktuellen_ noch ausstehenden Sektor ungleich Null. Führen Sie smartctl -d ata -t long /dev/sdaeinen zerstörungsfreien Selbsttest auf Ihrer Festplatte aus. Der normale Betrieb des Systems wird dadurch nicht unterbrochen. Wenn die geschätzte Zeit abgelaufen ist, führen Sie sie smartctl -d ata /dev/sdaerneut aus und überprüfen Sie im Selbsttestprotokoll, ob sie bestanden wurde.

Wenn etwas nicht perfekt aussieht, tauschen Sie das Laufwerk aus.

Erwägen Sie in Zukunft, diese Tests über smartdzu automatisieren, um frühzeitig vor Laufwerksausfällen zu warnen.

(Der Inhalt dieses Beitrags wurde durch Aktualisierungen der Frage überholt. Wenn Sie ein ähnliches Problem beheben, lesen Sie den Bearbeitungsverlauf dieser Antwort.)