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 ne doit être utilisée qu'en dernier ressort quand le serveur ne démarre plus à cause d'une telle corruption.

Après avoir lancé cette commande, il doit ê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 sont substituées aux données manquantes. La plupart des champs correspondent 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 doit ê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 peut ê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 doit ê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. Ces noms sont aussi en hexadécimal et ont trois parties. La première est le << timeline ID >> et doit habituellement être conservée identique. Ne choisissez pas de valeur plus importante que 255 (0xFF) pour la troisième partie ; à la place, incrémentez la deuxième partie et réinitialisez la troisième partie à 0. Par exemple, si 00000001000000320000004A est l'entrée la plus importante de pg_xlog, -l 0x1,0x32,0x4B fonctionnera ; mais si l'entrée la plus importante est 000000010000003A000000FF, choisissez -l 0x1,0x3B,0x0 ou plus. 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, il n'est pas critique d'obtenir le bon 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 qui peut être utile pour une vérification avant de permettre à pg_resetxlog de traiter réellement la base.

Notes

Cette commande ne doit pas être utilisée si le serveur est en cours d'exécution. pg_resetxlog refuse de se lancer s'il trouve un fichier de verrouillage du serveur dans le répertoire des données ; Si le serveur s'est arrêté brutalement, il peut subsister un tel fichier. 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'autre processus serveur en cours.