Come posso risolvere Postgres in modo che si avvii dopo un arresto improvviso?

Question

A causa di un'interruzione improvvisa dell'alimentazione, il server PostGres in esecuzione sul mio computer locale si è arrestato bruscamente. Dopo il riavvio, ho provato a riavviare postgres e ottengo questo errore:

$ 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 

Non v'è alcun file postmaster.pid nella directory dei dati. Quale potrebbe essere la ragione per questo tipo di comportamento e, naturalmente, quale è la via d'uscita?

Answer 1

La prima cosa che proverei è eseguire fsck su quel disco se non lo hai già fatto.

Answer 2

Leggendo alcuni messaggi simili negli archivi della mailing list di PostgreSQL ("sync archiviazione fallito su disco magnetico: Nessun file o directory") sembra indicare che c'è una seria hardware guai, molto peggio di una semplice interruzione di corrente. Potrebbe essere necessario prepararsi per ripristinare dai backup.

Answer 3

Avresti bisogno di pg_resetxlog. Dopo questo, il database può trovarsi in uno stato incoerente, quindi esegui il dump con pg_dumpall, ricomincia e reimporta.

A causa di questo potrebbe essere:

• Non hai disattivato la cache in scrittura hardware su disco, che spesso impedisce al sistema operativo da assicurandosi che i dati vengono scritti prima che i rapporti di scrittura di successo per l'applicazione. Controllare con

  hdparm -I /dev/sda

  Se mostra "*" prima "Scrivi cache" allora questo potrebbe essere il caso. Source of PostgreSQL ha un programma src/tools/fsync/test_fsync.c, che verifica la velocità di sincronizzazione dei dati con il disco. Esegui - se riporta tutte le volte più brevi di, ad esempio, 3 secondi di quanto il tuo disco sta mentendo al sistema operativo - su dischi da 7500rpm un test di 1000 scritture nello stesso posto avrebbe bisogno di almeno 8 secondi per completare (1000/(7500rpm/60s)) in quanto può scrivere solo una volta per percorso. Avresti bisogno di modificare questa test_fsync.c se il database è su un altro disco di partizione/var/tmp - cambiare

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

  a

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

• Il disco sta venendo a mancare e ha un blocco errato, controlla con badblocks.

• Si dispone di una RAM difettosa, verificare con memtest86+ per almeno 8 ore.

Answer 4

Avvia avvio anziché riavvio. Esegui il comando seguente: