Documentation PostgreSQL 14.22 » Référence » Applications relatives au serveur PostgreSQL » pg_resetwal

Précédent | Niveau supérieur | Suivant
pg_ctl | Sommaire | pg_rewind

## pg_resetwal

pg_resetwal — réinitialiser les WAL et les autres informations de contrôle d'une instance PostgreSQL

## Synopsis

`pg_resetwal` [ `-f` | `--force` ] [ `-n` | `--dry-run` ] [`option`...] [ `-D` | `--pgdata` ]`répertoire_données`

## Description

`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 incohérences 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.

## Options

`-f`
`--force`

  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`
`--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`
`--version`

  Affiche les informations de version, puis quitte.

`-?`
`--help`

  Affiche 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`.

`-c `xid`,`xid``
`--commit-timestamp-ids=`xid`,`xid``

  Configure 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_epoch``

  Configure 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_wal``

  Configure 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.

  ### Note

  `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`,`mxid``

  Configure 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 `xid``

  Configure 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=`oid``

  Configure 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=`mxoff``

  Configure 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_size``

  Configure 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.

  ### Note

  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=`xid``

  Configure 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).

## Environment

`PG_COLOR`

  Précise s'il faut utiliser des couleurs dans les messages de diagnostic. Les valeurs possibles sont `always`, `auto`, `never`.

## Notes

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.

## Voir aussi

pg_controldata