panique suite à une erreur postgresql: impossible de trouver un enregistrement valide à un point de contrôle

il cherche un enregistrement 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.0
pg_resetxlog DATADIR

# Postgres >= 10.0
pg_resetwal DATADIR

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

le serveur de base de données n'a pas été éteint proprement. La réinitialisation de la journal des transactions peut provoquer une perte de données. Si vous souhaitez continuer bref, utilisez-f pour forcer la réinitialisation.

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

# Postgres < 10.0
pg_resetxlog -f DATADIR 

# Postgres >= 10.0
pg_resetwal -f DATADIR

qui devrait réinitialiser le journal des transactions, mais il pourrait laisser votre base de données dans un état indéterminé comme expliqué dans la documentation PostgreSQL sur pg_resetxlog :

si pg_resetxlog se plaint qu'il ne peut pas déterminer les données valides pour pg_control, vous pouvez le forcer à continuer de toute façon, en spécifiant le commutateur -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 une assistance manuelle peut être nécessaire pour les champs suivants: ido, ID de transaction et epoch, ID de multitransaction et offset, et adresse de départ WAL. Ces champs peuvent être définis en utilisant les commutateurs discuté ci-dessous. Si vous n'êtes pas en mesure de déterminer des valeurs correctes pour tous ces champs, -f peut encore être utilisé, mais la base de données récupérée doit être traitée avec encore plus de suspicion que d'habitude: un dump immédiat et un rechargement est impératif. N'exécutez aucune opération de modification de données dans la base de données avant de procéder au dump, car une telle action est susceptible d'aggraver la corruption.

j'exécute 9.1.7 et je trouve exécuté avec succès ce qui suit:

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

votre argument final à la commande pg_resetxlog devrait être l'emplacement sur le disque où postgres stocke vos données de base de données.

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

faites-vous de l'archivage continu? Si vous sauvegardez à la fois, vous pouvez trouver qu'il est plus prudent de supprimer backup_label. pg_resetxlog est une chose grave.

comme le dit le journal de bord : impossible de localiser un enregistrement de point de contrôle valide.Postgres ne peut pas trouver un WAL correctement sous le répertoire $ PGDATA/pg_xlog/. Essayez d'utiliser pg_resetxlog