pg_resetxlog

Description

pg_resetxlog efface les WAL et réinitialise en option quelques autres informations de contrôle (stockées dans le fichier pg_control). Cette fonction est quelque fois nécessaire si ces fichiers ont été corrompus. Elle devrait être utilisée seulement en dernier ressort quand le serveur ne démarre plus à cause d'une telle corruption.

Après avoir lancé cette commande, il devrait être possible de lancer ce serveur, mais gardez en tête que la base de données pourrait contenir des données non cohérentes à cause de transactions partiellement validées. Vous devriez immédiatement sauvegarder vos données, lancer initdb et recharger. Après rechargement, vérifiez les incohérences et réparez si nécessaire.

Cet outil peut seulement être lancé par l'utilisateur qui a installé le serveur parce qu'il requiert un accès en lecture/écriture dans le répertoire des données. Pour des raisons de sécurité, vous devez spécifier le répertoire des données sur la ligne de commande. pg_resetxlog n'utilise pas la variable d'environnement PGDATA.

Si pg_resetxlog se plaint de ne pas pouvoir déterminer de données valides pour pg_control, vous pouvez malgré tout le forcer à continuer en spécifiant l'option -f (force). Dans ce cas, des valeurs probables seront substituées aux données manquantes. La plupart des champs correspondront mais une aide manuelle pourrait être nécessaire pour le prochain OID, le prochain TID, l'adresse de début des WAL et les champs locale des bases de données. Les trois premiers peuvent être initialisés en utilisant les options discutées plus bas. Le propre environnement de pg_resetxlog est la source de ses suppositions quant aux champs locale ; faites attention que LANG et d'autres correspondent à l'environnement avec lequel initdb a été exécuté. Si vous n'êtes pas capable de déterminer les bonnes valeurs pour tous ces champs, -f peut toujours être utilisé mais la base de données récupérée devra être traitée avec encore plus de suspicion que d'habitude : une sauvegarde immédiate et un rechargement sont impératifs. Ne pas exécuter d'opérations de modifications de données dans la base avant de sauvegarder ; ce type d'action risque de faire empirer la corruption.

Les options -o, -x et -l permettent d'initialiser manuellement le prochain OID, le prochain TID et l'adresse de début des WAL. Elles sont seulement nécessaires si pg_resetxlog est incapable de déterminer les valeurs appropriées en lisant pg_control. Une valeur saine pour la prochaine ID en transaction pourrait être déterminée en cherchant le nom de fichier le plus large numériquement dans le répertoire pg_clog sous le répertoire des données, en ajoutant un et en multipliant par 1048576. Notez que les noms de fichiers sont en hexadécimal. Il est habituellement plus facile de spécifier la valeur de l'option en hexadécimal aussi. Par exemple, si 0011 est l'entrée la plus large dans pg_clog, -x 0x1200000 fonctionnera (cinq zéros à la fin fournissent le bon multiplieur). L'adresse de début des WAL devrait être plus large que tout numéro de fichier déjà existant dans le répertoire pg_xlog sous le répertoire des données. Les adresses sont aussi en hexadécimal et ont deux parties. Par exemple, si 000000FF0000003A est l'entrée la plus large dans pg_xlog, -l 0xFF,0x3B fonctionnera. Il n'y a pas de façon plus simple pour déterminer un OID suivant qui se trouve après celui de la base de données mais, heureusement, ce n'est pas critique pour obtenir l'OID suivant.

L'option -n (sans opération) demande à pg_resetxlog d'afficher les valeurs reconstruites à partir de pg_control puis quitte sans rien modifier. C'est principalement un outil de débogage mais pourrait être utile pour une vérification de santé avant de permettre à pg_resetxlog de traiter en réel.

Notes

Cette commande ne doit pas être utilisée si le serveur est en cours d'exécution. pg_resetxlog refusera de se lancer s'il trouver un fichier de verrouillage du serveur qui aurait été oublié ; dans ce cas, vous pouvez supprimer le fichier de verrouillage pour permettre à pg_resetxlog de se lancer. Mais avant de le faire, soyez doublement certain qu'il n'y a pas de postmaster ou d'autres processus serveur en cours.