web-dev-qa-db-fra.com

Comment puis-je réparer Postgres pour qu'il démarre après un arrêt brutal?

En raison d'une panne de courant soudaine, le serveur PostGres exécuté sur mon ordinateur local s'est arrêté brusquement. Après avoir redémarré, j'ai essayé de redémarrer postgres et j'ai l'erreur suivante:

$ 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

Il n'y a pas de fichier postmaster.pid dans le répertoire de données. Quelle pourrait être la raison de ce type de comportement et quelle est la solution?

postgresqlrecovery
14
crashekar

Vous auriez besoin de pg_resetxlog . Cependant, votre base de données peut être dans un état incohérent après cela, alors videz-la avec pg_dumpall, recréez et importez à nouveau.

Une cause à cela pourrait être:

  • Vous n'avez pas désactivé le cache d'écriture matérielle sur le disque, ce qui empêche souvent le système d'exploitation de s'assurer que les données sont écrites avant de signaler le succès de l'écriture dans l'application. Vérifier avec

    hdparm -I /dev/sda

    Si "*" apparaît avant "Cache en écriture", cela pourrait être le cas. Source de PostgreSQL a un programme src/tools/fsync/test_fsync.c, qui teste la vitesse de synchronisation des données avec le disque. Exécutez-le - s'il signale tous les temps inférieurs à, disons, 3 secondes par rapport à votre disque ment par le système d'exploitation - sur un disque de 7500 tr/min, un test de 1 000 écritures au même endroit nécessite au moins 8 secondes pour se terminer (1000/(7500 tr/min/60)) car il ne peut écrire qu'une fois par route. Vous devrez éditer ce test_fsync.c si votre base de données est sur un autre disque que la partition/var/tmp - changez

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

    à

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

  • Votre disque est en panne et contient un bloc défectueux. Vérifiez avec badblocks .

  • Vous avez une mauvaise RAM, vérifiez avec memtest86 + pendant au moins 8 heures.

19
Tometzky

La lecture de quelques messages similaires dans les archives de la liste de diffusion PostgreSQL ("échec de la synchronisation du stockage sur disque magnétique: aucun fichier ou répertoire de ce type") semble indiquer qu'il existe un problème matériel très grave, bien pire qu'une simple panne de courant. Vous devrez peut-être vous préparer à restaurer à partir de sauvegardes.

6
bortzmeyer

Exécutez start au lieu de redémarrer. Exécutez la commande ci-dessous:

$pg_ctl -D /usr/local/pgsql/data start
0
Venu Madhav

Si j'avais eu la corruption aussi, mes actions

docker run -it --rm -v /path/to/db:/var/lib/postgresql/data postgres:10.3 bash
su - postgres
/usr/lib/postgresql/10/bin/pg_resetwal -D /var/lib/postgresql/data -f
0
srghma