pg_resetwal — réinitialiser les WAL et les autres informations de contrôle d'une grappe de bases de données PostgreSQL
pg_resetwal [-f] [-n] [option...] {[-D] rép_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.
À 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_resetwal 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_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.
-f
Force pg_resetwal à continuer même s'il ne peut pas
déterminer de données valides pour pg_control,
comme expliquées ci-dessus.
-n
L'option -n (pas d'opération) 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 utilise 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 comem 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.
-c 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_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 xlogfileConfigure manuellement l'adresse de démarrage du WAL.
L'adresse de démarrage du WAL devrait être plus grosse 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.
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,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.
-o 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 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.
-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).
-x 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).
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.
pg_resetxlog fonctionne seulement avec les serveurs de
la même version majeure.