pg_resetxlog — réinitialiser les WAL et les autres informations de contrôle d'une grappe de bases de données PostgreSQL™
pg_resetxlog [-f] [-n] [-o oid ] [-x xid ] [-e xid_epoch ] [-m mxid ] [-O mxoff ] [-l timelineid , fileid , seg ] rép_données
pg_resetxlog efface les jouranux d'écritures anticipées ( Write-Ahead Log ou WAL) et réinitialise optionnellement quelques autres informations de contrôle stockées dans le fichier pg_control. Cette fonction est parfois 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 du fait d'une telle corruption.
À la suite de cette commande, le serveur doit pouvoir redémarrer. Toutefois, il ne faut pas perdre de vue que la base de données peut contenir des données inconsistantes du fait de transactions partiellement validées. Il est alors opportun de sauvegarder les données, lancer initdb et de les recharger. Après cela, les inconsistances doivent être recharchées et le cas échéant corrigées.
Seul l'utilisateur qui a installé le serveur peut utiliser cet outil. Il requiert, en effet, un accès en lecture/écriture au répertoire des données. Pour des raisons de sécurité, pg_resetxlog n'utilise pas la variable d'environnement PGDATA. Le répertoire des données doit donc être précisé sur la ligne de commande.
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 et sa date, le prochain ID multi-transaction et son décalage, l'adresse de début des WAL et les champs locale des bases de données. Les six 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, -e, -m, -O et -l permettent d'initialiser manuellement le prochain OID, le prochain TID et sa date, le prochain ID multitransaction, son décalage 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. Les valeurs saines pour le prochain ID en transaction peuvent se déterminer ainsi :
Une bonne valeur du prochain ID de transaction (-x) peut être déterminée en recherchant le 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).
Une valeur saine pour le prochain ID multitransaction (-m) peut être déterminée en recherchant le nom de fichier le plus important numériquement dans le sous-répertoire pg_multixact/offsets du répertoire data, en lui ajoutant un, puis en le multipliant par 65536. Comme ci-dessus, les noms de fichiers sont en hexadécimal, donc la façon la plus simple de le faire est de spécifier la valeur de l'option en hexadécimal et de lui ajouter quatre zéros.
Une valeur saine pour le prochain décalage multitransaction (-O) peut être déterminée en recherchant le nom de fichier le plus important numériquement dans le sous-répertoire pg_multixact/members du répertoire data, en lui ajoutant un, puis en le multipliant par 65536. Comme ci-dessus, les noms de fichiers sont en hexadécimal, donc la façon la plus simple de le faire est de spécifier la valeur de l'option en hexadécimal et de lui ajouter quatre zéros.
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.
La valeur epoch de l'identifiant de transaction n'est pas réellement stockée dans la base, sauf dans le champ qui est initialisé par pg_resetxlog , donc toute valeur sera correcte en ce qui concerne la base de données elle-même. Vous pourrez avoir besoin d'ajuster cette valeur pour vous assurer que les systèmes de réplication comme Slony-I fonctionnent correctement -- dans ce cas, une valeur appropriée doit être obtenue à partir de l'état de la base répliquée.
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.
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 processus serveur en cours.
pg_ctl
