Comment réparer Postgres afin qu'il démarre après un arrêt brusque?

En raison d'une coupure de courant soudaine, le serveur PostGres s'exécutant sur ma machine locale s'est arrêté brusquement. Après le redémarrage, j'ai essayé de redémarrer Postgres et je reçois cette erreur:Comment réparer Postgres afin qu'il démarre après un arrêt brusque?

$ 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. Ce qui pourrait éventuellement être la raison de ce genre de comportement et bien sûr, quelle est la sortie?

Source

2009-02-28 Anonymous

Juste pour que vous le savez, les chances sont que vous pourriez avoir à restaurer à partir de sauvegarde. Mais avant cela, partagez avec nous votre version de Postgres (v8.1.5 et v8.1.6 IIRC il y avait un bogue déclenchant cette erreur pendant la récupération) et le type de système de fichiers (vous voudrez peut-être changer cela avant la panne suivante) – vladr

indice: "restart", vous dites à PostgreSQL qu'il est en cours d'exécution et doit être redémarré. Il ne fonctionne pas, il n'y a donc pas de fichier d'identification de processus (.pid). – Kurt

Quelle version de postgres utilisez-vous, et quel est le type du système de fichiers '/ usr/local/pgsql/data'? – vladr

La première chose que j'essaierais est d'exécuter fsck sur ce disque si vous ne l'avez pas déjà fait.

Source

2009-02-28 16:12:49 flussence

Lire quelques messages similaires dans les archives de la liste de diffusion PostgreSQL (« synchronisation de stockage a échoué sur le disque magnétique: Aucun fichier ou répertoire ») semble indiquer qu'il existe un matériel très sérieux problème, bien pire qu'une simple panne de courant. Vous devrez peut-être vous préparer à restaurer à partir de sauvegardes.

Source

2009-02-28 17:57:00 bortzmeyer

Fourmi P, Vlad Romascanu et bortzmeyer - Merci pour tous vos commentaires. J'ai compris que le disque dur a été corrompu à cause du pic de puissance. Je dois déplacer postgres à une autre machine. –

Si c'était correct, vous pouvez changer les deux réponses (un moron downvoted mine sans prendre la peine d'expliquer pourquoi). – bortzmeyer

@bortzmeyer: Mise à jour en raison de la bonne réponse. –

Vous auriez besoin de pg_resetxlog. Votre base de données peut être dans un état incohérent après cela, alors vider avec pg_dumpall, recréer et réimporter.

Une cause de cela pourrait être:

Vous n'avez pas désactivé le matériel cache d'écriture sur le disque, qui souvent empêche le système d'exploitation de rendre les données sûres est écrit avant qu'il fasse rapport écriture avec succès à l'application. Vérifiez avec

hdparm -I /dev/sda

Si elle montre « * » avant « cache en écriture », cela pourrait être le cas. Source of 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 rapporte tous les temps plus courts que, disons, 3 secondes que votre disque est à OS - sur un disque 7500rpm un test de 1000 écritures au même endroit aurait besoin d'au moins 8 secondes pour terminer (1000/(7500rpm/60s)) car il ne peut écrire qu'une seule fois par route. Vous aurez besoin de modifier cette test_fsync.c si votre base de données est sur un autre disque que la partition/var/tmp - changer

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

à

#define FSYNC_FILENAME "/usr/local/pgsql/data/test_fsync.out"
Votre disque est défaillant et a un mauvais bloc, vérifiez avec badblocks. Vous avez une mauvaise RAM, vérifiez avec memtest86+ pendant au moins 8 heures.

Source

2009-03-02 10:58:05 Tometzky

Merci beaucoup. J'avais déménagé la DB, mais j'ai décidé d'essayer votre option. Cela a fonctionné et le db est restauré. pg_resetxlog a fait l'affaire. –

Ce problème peut également survenir lors de la mise à niveau d'un système d'exploitation Windows - Non seulement le postmaster devient inaccessible, mais les autorisations sur le dossier de données et le service peuvent disparaître. pg_resetxlog résout le premier problème. – MytyMyky

Cela peut également se produire simplement avec un sous-système de stockage incroyablement surchargé sur Linux. –

Exécutez le démarrage au lieu du redémarrage. Exécutez la commande ci-dessous:

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

Source

2009-08-07 05:06:40

Je reçois toujours la même erreur quand je le fais. – student001

Comment réparer Postgres afin qu'il démarre après un arrêt brusque?

Répondre

Questions connexes