Używam Fedora 15z PostgreSQL 9.1.4. Fedora niedawno uległa awarii, po czym:

Próba uruchomienia serwera PostgreSQL:

service postgresql-9.1 start

daje

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

Chociaż serwer uruchamia się normalnie, gdy uruchamiam go po raz pierwszy po ponownym uruchomieniu systemu .
Ale próba użycia psqlpowoduje następujący błąd:

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.5432plik nie jest nigdzie w systemie. A locate .s.PGSQL.5432Wyjścia nic.

Dziennik systemu ma to:

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.

ZA

systemctl status postgresql-9.1.service

daje

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

Nie zmieniłem domyślnego ustawienia fsync, więc zgaduję, że było ustawione na on. Jestem na dysku twardym. Dysk twardy się zawiesił.

Awaria dysku twardego

Awaria dysku twardego spowodowała uruchomienie instrukcji fsckw trybie szybkim i bez interfejsu GUI. Dzięki niemu naprawia iglice gazillionowe itp. Następnie zrestartowałem system za pomocą Ctrl+ Alt+ Delete.

Dziennik PostgreSQL ma to:

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

Aktualizacja

Próba uruchomienia serwera po pobraniu kopii /var/lib/pgsqlkatalogu na poziomie systemu plików i uruchomieniu ./pg_resetxlog -f /var/lib/pgsql/9.1/data/z wynikiem xlog -f /var/lib/pgsql/9.1/data/nadal daje:

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

Prawdziwa odpowiedź będzie w dziennikach PostgreSQL w /var/lib/pgsql/data/pg_log.

Zanim jednak podejmiesz jakiekolwiek działanie: przed podjęciem próby naprawy należy wykonać kopię bazy danych na poziomie systemu plików, jeśli jakiekolwiek dane są dla Ciebie cenne . Zobacz http://wiki.postgresql.org/wiki/Corruption . Musisz skopiować cały katalog danych. W Fedorze jest to /var/lib/pgsql/datadomyślnie, ale sprawdź, czy jest poprawne dla twojej instalacji.

Na podstawie opublikowanych dzienników z pewnością masz pewien stopień uszkodzenia bazy danych. Pamięć, w której znajduje się baza danych (dysk twardy lub system plików), najprawdopodobniej jest uszkodzona. Zrób kopię TERAZ i umieść ją na innym dysku twardym lub systemie .

Dopiero po utworzeniu pełnej kopii katalogu danych na poziomie systemu plików spróbuj użyć pg_resetxlog, aby wyczyścić uszkodzone dzienniki transakcji i uruchomić bazę danych. Nawet jeśli się zacznie, jest wysoce prawdopodobne, że zostanie uszkodzony; powinieneś pg_dumpto zrobić ponownie initdbi przywrócić zrzut do nowej instancji.

Jeśli nadal nie możesz go uruchomić po tym, pg_resetxlogopublikuj zaktualizowany dziennik próby uruchomienia po resecie. Możliwe, że będziesz musiał uruchomić PG w trybie autonomicznym z:

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

Jeśli to zadziała, pojawi się backend>monit, spróbuj ponownie po zamianie ostatniego „postgres” na nazwę bazy danych, z którą chcesz się połączyć. Powinieneś być w stanie SELECT, COPYdane z tabel itp.

Jeśli to nie zadziała, tzn. Nie możesz uruchomić samodzielnego backendu, prawdopodobnie nadszedł czas, aby przywrócić z kopii zapasowych - ponieważ jesteś na tyle rozsądny, aby je mieć. Jeśli ktokolwiek czytający to jest w tej samej pozycji, skontaktuj się z doświadczonym konsultantem PostgreSQL, aby sprawdzić, czy może odzyskać dane z Twojej bazy danych. Przygotuj się na opłacenie czasu i wiedzy.

Twój system plików jest prawdopodobnie uszkodzony

Powaga uszkodzenia instalacji PostgreSQL sugeruje, że prawdopodobnie cały system plików jest uszkodzony. Możesz rozważyć przywrócenie całego systemu z kopii zapasowej lub jego ponowną instalację.

Nie ufałbym temu systemowi plików fscklub nie fsck.

SMART-przetestuj swój dysk

Polecam również SMARTsprawdzenie na dysku twardym za pomocą smartctlsmartmontools; zakładając, /dev/hdaże tak będzie smartctl -d ata -a /dev/sda | less. Poszukaj nieudanego testu kondycji, uncorrectable_sectorswysokiego wskaźnika błędów odczytu, ponownie przydzielonego_sektora_liczenia większego niż 2 lub 3 lub niezerowego prądu_sektora_ oczekującego. Uruchom, smartctl -d ata -t long /dev/sdaaby wykonać nieniszczący autotest na dysku twardym; nie zakłóci to normalnego funkcjonowania systemu. Po upływie szacowanego czasu uruchom smartctl -d ata /dev/sdaponownie i spójrz na dziennik autotestu, aby sprawdzić, czy upłynął.

Jeśli coś wygląda mniej niż idealnie, wymień dysk.

W przyszłości rozważ zautomatyzowanie tego testowania poprzez smartdwczesne ostrzeganie o awariach dysków.

(Treść tego postu była przestarzała z powodu aktualizacji pytania. Jeśli rozwiązujesz podobny problem, przejrzyj historię edycji tej odpowiedzi).