2009-02-28 10 views
13

Z powodu nagłej awarii zasilania, serwer lokalny na mojej lokalnej maszynie nagle się wyłączył. Po ponownym uruchomieniu komputera, próbowałem ponownie uruchomić postgres i otrzymuję ten błąd:Jak naprawić PostgreSQL, aby zaczął się po nagłym wyłączeniu?

$ pg_ctl -D /usr/local/pgsql/data restart

pg_ctl: PID file "/usr/local/pgsql/data/postmaster.pid" does not exist 
Is server running? 
starting server anyway 
server starting 
$:/usr/local/pgsql/data$ LOG: database system shutdown was interrupted at 2009-02-28 21:06:16 
LOG: checkpoint record is at 2/8FD6F8D0 
LOG: redo record is at 2/8FD6F8D0; undo record is at 0/0; shutdown FALSE 
LOG: next transaction ID: 0/1888104; next OID: 1711752 
LOG: next MultiXactId: 2; next MultiXactOffset: 3 
LOG: database system was not properly shut down; automatic recovery in progress 
LOG: redo starts at 2/8FD6F918 
LOG: record with zero length at 2/8FFD94A8 
LOG: redo done at 2/8FFD9480 
LOG: could not fsync segment 0 of relation 1663/1707047/1707304: No such file or directory 
FATAL: storage sync failed on magnetic disk: No such file or directory 
LOG: startup process (PID 5465) exited with exit code 1 
LOG: aborting startup due to startup process failure 

nie ma pliku w katalogu danych postmaster.pid. Co może być przyczyną takiego zachowania i oczywiście, jakie jest wyjście?

+0

Tak, wiesz, możliwe, że będziesz musiał przywrócić z kopii zapasowej. Ale zanim to zrobisz, podziel się z nami swoją wersją PostgreSQL (w wersji 8.1.5 i 8.1.6 IIRC wystąpił błąd powodujący ten błąd podczas odzyskiwania) i typ systemu plików (możesz chcieć to zmienić przed następnym przestojem). – vladr

+0

Wskazówka: "restart", mówisz serwerowi PostgreSQL, że działa i trzeba go zrestartować. Nie działa, dlatego nie ma pliku identyfikatora procesu (.pid). – Kurt

+0

Jakiej wersji Postgreszu używasz i jaki jest typ systemu plików dla '/ usr/local/pgsql/data'? – vladr

Odpowiedz

0

Najpierw spróbuję uruchomić na tym dysku fsck, jeśli jeszcze tego nie zrobiłeś.

6

przeczytaniu kilku podobnych wiadomości w archiwach listy PostgreSQL („sync przechowywania zawiodły na dysku magnetycznego: Nie ma takiego pliku lub katalog”) wskazuje na to, że istnieje bardzo poważny sprzętu kłopot, dużo gorzej niż zwykła awaria zasilania. Być może będziesz musiał przygotować się do przywrócenia z kopii zapasowych.

+0

Ant P, Vlad Romascanu i bortzmeyer - Dziękuję za wszystkie wasze commennty. Dowiedziałem się, że dysk twardy został uszkodzony z powodu skoku zasilania. Muszę przenieść postgres na inną maszynę. –

+0

Jeśli był poprawny, możesz poprzeć dwie odpowiedzi (jeden głupek zignorował moje, nie zadając sobie trudu, by wyjaśnić dlaczego). – bortzmeyer

+0

@bortzmeyer: Wznowienie z powodu poprawnej odpowiedzi. –

18

Musisz być pg_resetxlog. Twoja baza danych może być w tym stanie niespójna, więc zrzuć ją za pomocą pg_dumpall, odtwórz i importuj ponownie.

Przyczyną tego może być:

  • Nie wyłączony sprzętu zapisu pamięci podręcznej na dysku, który często zapobiega OS od upewniając dane są zapisywane przed zgłasza to udany zapis do aplikacji. Sprawdź u

    hdparm -I /dev/sda

    Jeśli pokazuje "*" przed "Write cache" to może być przypadek. Source of PostgreSQL ma program src/tools/fsync/test_fsync.c, który testuje prędkość synchronizowania danych z dyskiem. Uruchom - jeśli raport będzie zawsze krótszy niż, powiedzmy, 3 sekundy, niż twój dysk leży na OS - na dyskach 7500rpm test 1000 zapisów do tego samego miejsca będzie potrzebował co najmniej 8 sekund na zakończenie (1000/(7500rpm/60s)), ponieważ może pisać tylko raz na trasie. trzeba by edytować test_fsync.c jeśli baza danych znajduje się na innym dysku niż/var/tmp partycji - zmiana

    #define FSYNC_FILENAME "/var/tmp/test_fsync.out"

    do

    #define FSYNC_FILENAME "/usr/local/pgsql/data/test_fsync.out"

  • Twój dysk zawodzi i ma zły blok, sprawdź z badblocks.

  • Masz złą pamięć RAM, sprawdź na memtest86+ przez co najmniej 8 godzin.

+0

Dzięki za tonę. Przeniosłem DB, ale postanowiłem spróbować. To zadziałało i db został przywrócony. pg_resetxlog zrobił lewy. –

+0

Ten problem może się również zdarzyć, gdy pojawi się uaktualnienie systemu operacyjnego Windows - nie tylko postmaster staje się niedostępny, ale uprawnienia folderu danych i usługi mogą zniknąć. pg_resetxlog rozwiązuje pierwszy problem. – MytyMyky

+0

To może się również zdarzyć z niesamowicie przeciążonym podsystemem pamięci masowej w systemie Linux. –

0

Uruchomienie zamiast ponownego uruchomienia. Wykonaj poniższą komendę:

$pg_ctl -D /usr/local/pgsql/data start 
+0

Wciąż mam ten sam błąd, kiedy to robię. – student001

Powiązane problemy