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] [option...] {[-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.
Force pg_resetxlog à continuer même s'il ne peut pas déterminer de données valides pour pg_control, comme expliquées ci-dessus.
L'option -n (pas d'opération) demande à pg_resetxlog 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_resetxlog à réaliser des modifications.
Affiche les informations de version, puis quitte.
Affiche l'aide, puis quitte.
Les options suivantes sont seulement nécessaires quand pg_resetxlog 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.
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.
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_resetxlog, donc n'importe quelle valeur fonctionnera. Vous pourriez avoi 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.
Configure 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_xlog 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_xlog, utilisez -l 00000001000000320000004B ou plus haut.
![[Note]](../images/note.png)
pg_resetxlog recherche lui-même les fichiers dans pg_xlog 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_xlog, comme les entrées d'une archive hors-ligne ou si le contenu de pg_xlog a été entièrement perdu.
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.
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.
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.
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).
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_clog 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_clog, -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_resetxlog 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_resetxlog. Mais avant de faire cela, assurez-vous qu'aucun processus serveur n'est toujours en cours d'exécution.
pg_resetxlog fonctionne seulement avec les serveurs de la même version majeure.
pg_ctl