pg_resetxlog — réinitialiser les WAL et les autres informations de contrôle d'une grappe de bases de données PostgreSQL™
pg_resetxlog [-c xid,xid] [-f] [-n] [-o oid] [-x xid] [-e xid_epoch] [-m mxid,mxid] [-O mxoff] [-l xlogfile] {[-D] rép_données}
pg_resetxlog efface les journaux 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 recherché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 identifiant multi-transaction et son décalage, l'adresse de début des journaux de transactions. Ces champs peuvent être configurés en utilisant les options indiquées ci-dessus. 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, -c et -l permettent d'initialiser manuellement le prochain OID, le prochain TID, l'ancien et le prochain ID multitransaction, son décalage, le plus ancien et le plus récent identifiants de transaction pour lesquels l'horodatage du COMMIT peut être récupéré, 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 (première partie de la valeur de l'option -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. En revanche, une valeur sûre pour le plus ancien ID multitransaction (deuxième partie de la valeur de l'option -m) peut être déterminée par la recherche du nom de fichier le plus petit numériquement dans le même répertoire et en 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 52352. Comme ci-dessus, les noms de fichiers sont en hexadécimal. Il n'existe pas de solution simple comme ci-dessus avec l'ajout de zéros.
Une valeur sûre pour l'identifiant de transaction le plus ancien pour lequel un horodatage du COMMIT peut être récupéré (première partie de -c) peut être déterminé en regardant le plus petit nom de fichier (numériquement) du sous-répertoire pg_commit_ts du répertoire principal des données. De la même façon, une valeur sûre pour l'identifiant de transaction le plus récent pour lequel un horodatage du COMMIT peut être récupéré (deuxième partie de -c) peut être déterminé en regardant le plus grand nom de fichier (numériquement) du même répertoire. Comme ci-dessus, les noms de fichiers sont en hexadécimal.
L'adresse de début des WAL (-l) doit être plus large que tout nom de fichier de segment WAL 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. Par exemple, si 00000001000000320000004A est l'entrée la plus importante de pg_xlog, utilisez -l 00000001000000320000004B ou supérieur. ou plus.
![[Note]](../images/note.png)
pg_resetxlog lui-même recherche les fichiers dans pg_xlog et choisit un paramètre -l par défaut au-delà du dernier fichier existant. Du coup, un ajustement manuel de -l sera seulement nécessaire si vous avez connaissance de fichiers WAL qui ne sont actuellement pas présents dans le répertoire pg_xlog, comme des entrées dans une archive hors ligne ou si le contenu de pg_xlog avait complètement disparu.
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 et Skytools 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 et les valeurs à modifier, 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.
Les options -V et --version affichent la version de pg_resetxlog puis arrêtent l'application. Les options -? et --help affichent les arguments acceptés.
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_resetxlog fonctionne seulement avec les serveurs de la même version majeure.
pg_ctl