pg_resetwal — réinitialiser les WAL et les autres informations de contrôle d'une instance PostgreSQL
pg_resetwal [ -f | --force ] [ -n | --dry-run ] [option...] [ -D | --pgdata ]répertoire_données
pg_resetwal 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.
Certaines options, comme --wal-segsize (voir ci-dessous),
peuvent aussi être utilisées pour modifier certains paramétrages globaux
d'une instance de bases de données sans avoir besoin de réexécuter
initdb. Ceci peut se faire en toute sécurité sur une
instance en bon état, si aucun des modes dangereux mentionnés ci-dessous ne
sont utilisés.
Si pg_resetwal est utilisé sur un répertoire de données
où le serveur a été correctement arrêté et que le fichier de contrôle
est sain, alors il n'aura aucun effet sur le contenu du système de bases
de données, sauf que les journaux de transactions qui ne sont plus utilisés
seront effacés. Tout autre utilisation est potentiellement dangereuse et ne
doit être réalisé qu'avec une grande attention.
pg_resetwal nécessitera l'utilisation de l'option
-f (force) avant de travailler sur un répertoire de
données qui a été mal arrêté ou avec un fichier de contrôle corrompu.
Après avoir exécuté cette commande sur un répertoire de données contenant
des journaux de transactions corrompus ou un fichier de contrôle corrompu,
il devrait être possible de démarrer le serveur.
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 incohérences
doivent être recherchées et le cas échéant corrigées.
Si pg_resetwal 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.
Cet outil peut seulement être exécuté par l'utilisateur qui a installé le serveur car il nécessite un accès en lecture/écriture du répertoire des données.
datadir-D datadir--pgdata=datadir
Indique l'emplacement du répertoire de données. Pour des raisons de
sécurité, vous devez indiquer le répertoire des données sur la ligne de
commande. pg_resetwal n'utilise pas la variable
d'environnement PGDATA.
-f--force
Force pg_resetwal à continuer même dans des situations
où cela pourrait être dangereux comme expliqué ci-dessus. Plus
spécifiquement, cette option est requise si le serveur n'a pas été
arrêté normalement ou si pg_resetwal ne peut pas
trouver des données valides dans pg_control.
-n--dry-run
L'option -n/--dry-run demande à
pg_resetwal d'afficher les valeurs reconstruites à
partir de pg_control et les valeurs à modifier,
puis quitte sans faire aucune modification. C'est principalement un
outil de débugage, mais il peut être utilisé aussi comme outil de
vérification avant d'autoriser pg_resetwal à réaliser
des modifications.
-V--versionAffiche les informations de version, puis quitte.
-?--helpAffiche l'aide, puis quitte.
Les options suivantes sont seulement nécessaires quand
pg_resetwal est incapable de déterminer les valeurs
appropriées lors de la lecture de pg_control. Des
valeurs sûres peuvent être déterminées comme décrit ci-dessous. Pour les
valeurs prenant des arguments numériques, les valeurs hexadécimales peuvent
être précisées en utilisant le préfixe 0x. Notez que
ces instructions s'appliquent seulement avec la taille de bloc standard
de 8 Ko.
-c xid,xid--commit-timestamp-ids=xid,xidConfigure manuellement le plus ancien et le plus récent identifiant de transaction pour lesquels le temps de validation peut être retrouvé.
Une valeur sûre pour la plus ancienne transaction dont le temps de
validation peut être retrouvé (première partie) peut être déterminée en
recherchant le numéro de fichier le plus petit numériquement dans le
sous-répertoire pg_commit_ts du répertoire
principal des données. De la même manière, une valeur sûre pour
l'identifiant de transaction le plus récent dont le temps de validation
peut être retrouvé (deuxième partie) peut être déterminé en recherchant
le nom de fichier le plus grand numériquement dans le même répertoire.
Les noms de fichiers sont en hexadécimal.
-e xid_epoch--epoch=xid_epochConfigure manuellement l'epoch du prochain identifiant de transaction.
L'epoch de l'identifiant de transaction n'est pas enregistré
actuellement dans la base de données, en dehors du champ configuré par
pg_resetwal, donc n'importe quelle valeur
fonctionnera. Vous pourriez avoir besoin d'ajuster cette valeur pour
assurer que les systèmes de réplication comme
Slony-I et
Skytools fonctionnent correctement --
dans ce cas, une valeur appropriée est récupérable à partir de l'état de
la base de données répliquée.
-l fichier_wal--next-wal-file=fichier_walConfigure manuellement l'emplacement de démarrage du WAL en spécifiant le nom du prochain fichier de segment WAL.
Le nom du prochain fichier de segment WAL devrait être plus gros que le
nom des segments WAL existant actuellement dans le sous-répertoire
pg_wal sous le répertoire principal de données. Ces
noms sont aussi en hexadécimal et sont composés de trois parties. La
première partie est l'« identifiant de la ligne de temps » et
devrait être généralement identique. Par exemple, si
00000001000000320000004A est la plus large entrée
dans largest entry in pg_wal, utilisez -l
00000001000000320000004B ou plus haut.
Notez que, en utilisant des tailles non standards pour les segments WAL, les nombres dans les noms des fichiers WAL sont différents des LSN reportés par les fonctions systèmes et les vues systèmes. Cette option prend un nom de fichier WAL, pas un LSN.
pg_resetwal recherche lui-même les fichiers dans
pg_wal et choisit une configuration par défaut
pour -l au-dessus du dernier nom de fichier existant.
De ce fait, un ajustement manuel de -l est seulement
nécessaire si vous connaissez des fichiers de segments WAL qui ne sont
pas actuellement présents dans pg_wal, comme les
entrées d'une archive hors-ligne ou si le contenu de
pg_wal a été entièrement perdu.
-m mxid,mxid--multixact-ids=mxid,mxidConfigure manuellement le plus ancien et le prochain identifiants de multitransaction.
Une valeur sûre pour le prochain identifiant de multitransaction
(première partie) peut être déterminée en recherchant le nom de fichier
le plus élevé numériquement dans le sous-répertoire
pg_multixact/offsets du répertoire principal des
données, en ajoutant 1, puis en multipliant par 65536 (0x10000). De la
même façon, une valeur sûr pour l'identifiant de multitransaction le
plus ancien (deuxième partie de -m) peut être
déterminée en recherchant le nom de fichier le moins élevé numériquement
dans le même répertoire et en multipliant par 65536. Les noms de fichier
sont en hexadécimal, donc la façon la plus simple de le faire est de
spécifier la valeur en option en hexadécimal et d'ajouter quatre zéros.
-u xidConfigure manuellement le plus ancien identifiant de transaction non gelé.
Une valeur sûre peut être déterminée en recherchant le nom de fichier le
plus petit dans le sous-répertoire pg_xact du
répertoire des données et en le multipliant par 1048576
(0x100000). Notez que les noms de fichiers sont en hexadécimal. Il est
habituellement plus simple d'indiquer la valeur de cette option en
hexadécimal là-aussi. Par exemple, si 0007 est la
plus petite entrée dans pg_xact, -u
0x700000 fonctionnera (les cinq zéros en fin fournissent le
bon multiplieur).
-o oid--next-oid=oidConfigure manuellement le prochain OID.
Il n'existe pas de façon simple de déterminer le prochain OID, celui qui se trouve après le numéro le plus élevé dans la base de données. Heureusement, ce n'est pas critique de configurer correctement ce paramètre.
-O mxoff--multixact-offset=mxoffConfigure manuellement le prochain décalage de multitransaction.
Une valeur sûre peut être déterminée en recherchant le nom de fichier le
plus élevé numériquement dans le sous-répertoire
pg_multixact/members du répertoire principal des
données, en ajoutant 1, puis en multipliant par 52352 (0xCC80). Les noms
de fichier sont en hexadécimal. Il n'existe pas de recette simple telle
que celles fournies pour les autres options avec l'ajout de zéros.
--wal-segsize=wal_segment_sizeConfigure la nouvelle taille d'un segment WAL, en mégaoctets. La valeur doit être une puissance de 2 entre 1 et 1024 (mégaoctets). Voir la même option de initdb pour plus d'informations.
Cette option peut seulement être utilisé pour modifier la taille d'un
segment de journal de transactions, évitant ainsi le besoin de lancer
de nouveau initdb.
Bien que pg_resetwal configurera l'adresse de début
de WAL après le dernier fichier segment de WAL existant, certaines
modifications de taille de segment peuvent causer la réutilisation de
précédents noms de fichier WAL. Il est recommandé d'utiliser l'option
-l avec cette option pour configurer manuellement
l'adresse de début de WAL si une surcharge d'un nom de fichier WAL
causerait des problèmes avec votre stratégie d'archivage.
-x xid--next-transaction-id=xidConfigure manuellement la prochain identifiant de transaction.
Une valeur sûre peut être déterminée en recherchant le nom de fichier le
plus élevé numériquement dans le sous-répertoire
pg_xact du répertoire principal des données, en
ajoutant 1, puis en multipliant par 1048576 (0x100000). Notez que les
noms de fichier sont en hexadécimal. Il est généralement plus simple de
spécifier la valeur de l'option en hexadécimal. Par exemple, si
0011 est l'entrée la plus élevée dans
pg_xact, -x 0x1200000
fonctionnera (cinq zéros à l'arrière fournissent le bon multiplicateur).
PG_COLOR
Précise s'il faut utiliser des couleurs dans les messages de
diagnostique. Les valeurs possibles sont always,
auto, never.
Cette commande ne doit pas être utilisée quand le serveur est en cours
d'exécution. pg_resetwal refusera de démarrer s'il
trouve un fichier verrou du serveur dans le répertoire de données. Si le
serveur s'est arrêté brutalement, un fichier verrou pourrait être toujours
présent. Dans ce cas, vous pouvez supprimer le fichier verrou pour
permettre l'exécution de pg_resetwal. Mais avant de
faire cela, assurez-vous qu'aucun processus serveur n'est toujours en cours
d'exécution.
pg_resetwal fonctionne seulement avec les serveurs de la
même version majeure.