erreur postgresql PANIC : impossible de trouver un enregistrement de point de contrôle valide

Question

Lorsque je charge le serveur postgres (v9.0.1), j'obtiens une panique qui l'empêche de démarrer :

PANIC : n'a pas pu localiser un enregistrement de point de contrôle valide

Comment puis-je réparer cela ?

Answer 1

Il recherche un enregistrement de point de contrôle dans le journal des transactions qui n'existe probablement pas ou qui est corrompu. Vous pouvez déterminer si c'est le cas en exécutant :

# Postgres >= 10
pg_resetwal DATADIR

# Postgres < 10
pg_resetxlog DATADIR

Si le journal des transactions est corrompu, vous verrez un message comme :

Le serveur de base de données n'a pas été arrêté proprement. La réinitialisation du journal des transactions peut entraîner la perte de données. Si vous voulez continuer quand même, utilisez -f pour forcer la réinitialisation.

Vous pouvez ensuite suivre les instructions et exécuter avec -f pour forcer la mise à jour :

# Postgres >= 10
pg_resetwal -f DATADIR

# Postgres < 10
pg_resetxlog -f DATADIR 

Cela devrait réinitialiser le journal des transactions, mais cela pourrait laisser votre base de données dans un état indéterminé, comme expliqué dans l'article intitulé Documentation de PostgreSQL sur pg_resetwal :

Si pg_resetwal se plaint de ne pas pouvoir déterminer les données valides pour pg_control vous pouvez l'obliger à procéder quand même en spécifiant l'option -f (force). Dans ce cas, des valeurs plausibles seront substituées aux données manquantes. On peut s'attendre à ce que la plupart des champs correspondent, mais mais une assistance manuelle peut être nécessaire pour l'OID, l'ID et l'époque de la et l'époque, l'ID et le décalage de la transaction suivante, et l'emplacement de départ du WAL. et l'emplacement de départ du WAL. Ces champs peuvent être définis en utilisant les options discutées ci-dessous. Si vous n'êtes pas en mesure de déterminer les valeurs correctes de tous ces champs, vous pouvez les modifier. champs, -f peut toujours être utilisé, mais la base de données récupérée doit être récupérée doit être traitée avec encore plus de suspicion que d'habitude : un vidage et un rechargement immédiats sont impératifs. rechargement immédiat est impératif. N'exécutez aucune opération de modification des données dans la base de données avant de procéder au vidage. la base de données avant d'effectuer le vidage, car une telle action est susceptible d'aggraver la corruption. corruption.

Answer 2

J'utilise la version 9.1.7 et j'ai réussi à exécuter ce qui suit :

/usr/lib/postgresql/9.1/bin/pg_resetxlog -f /var/lib/postgresql/9.1/main

Votre dernier argument à la pg_resetxlog doit être l'emplacement sur le disque où postgres stocke les données de votre base de données.

Answer 3

Comme indiqué ici pg_resetxlog ne doit pas être exécuté. Les réponses qui y font référence sont de mauvais conseils. En supposant que l'erreur s'est produite dans un contexte de copie/réplication d'instance, le lien fournit une manière plus succincte de faire la copie/réplication avec pg_basebackup

Answer 4

Faites-vous de l'archivage continu ? Si vous effectuez des sauvegardes à ce moment-là, vous trouverez peut-être plus prudent de supprimer backup_label. pg_resetxlog est une chose grave.

Answer 5

Postgres ne peut pas trouver un fichier WAL correct dans le répertoire $PGDATA/pg_xlog/. Essayez d'utiliser pg_resetxlog.