| > > > | |
 pg_resetxlog
|
pg_test_fsync
|
pg_rewind — synchronise le répertoire des données de PostgreSQL™ avec un répertoire de données dupliqué depuis le premier
pg_rewind [option...] { -D | --target-pgdata } directory { --source-pgdata=répertoire | --source-server=chaine_de_connexion }
pg_rewind est un outil qui permet de synchroniser une instance PostgreSQL avec une copie de cette même instance, a postériori de la séparation des timelines. Le scénario classique consiste à réactiver un ancien serveur primaire, après une bascule, en tant que serveur secondaire répliqué depuis le nouveau serveur primaire.
Le résultat est le même que lorsqu'on remplace le répertoire de données cible avec celui de la source. Tous les fichiers sont copiés, fichiers de configurations compris. L'avantage de pg_rewind par rapport à la réalisation d'une nouvelle sauvegarde de base, ou l'utilisation d'un outil tel que rsync, est que pg_rewind n'a pas besoin de lire tous les fichiers qui n'ont pas été modifiés dans l'ancienne instance. Cela rend l'opération éminement plus rapide lorsqu'on est face à une volumétrie conséquente ou s'il a peu de différences entre les deux instances.
pg_rewind inspecte l'historique de la timeline de l'instance source et de l'instance cible pour déterminer à quel moment a eu lieu la séparation, et s'attend à trouver tous les fichiers WAL jusqu'au moment de la bascule dans le répertoire pg_xlog. Dans un scénario de bascule classique, où l'instance cible a été arrêtée peu après le changement, cela ne pose aucun problème. En revanche, si l'instance cible a travaillé un certain temps après le changement, les anciens fichiers WAL peuvent ne plus être présents dans le répertoire pg_xlog. Dans ce cas, ils peuvent être copiés à la main depuis les fichiers WAL archivés vers le répertoire pg_xlog. Récupérer les fichiers manquants en parcourant les fichiers WAL archivés n'est pour l'instant pas supporté.
Lorsque l'instance cible est démarrée pour la première fois après avoir utilisé pg_rewind, elle va se mettre en mode de restauration (recovery) et va rejouer tous les fichiers WAL générés par l'instance source depuis la bascule. Si certains fichiers WAL ne sont plus disponibles sur la source lorsque pg_rewind est en cours, ils ne peuvent donc plus être copiés par la session pg_rewind. Il est alors nécessaire de faire en sorte qu'ils puissent être disponibles lorsque le serveur cible sera démarré. Cela est possible en créant un fichier recovery.conf dans le répertoire principal cible des données, en utilisant le paramètre restore_command de manière appropriée.
pg_rewind nécessite que l'instance cible ait l'option wal_log_hints activée dans le fichier de configuration postgresql.conf ou que les sommes de contrôle sur les données aient été activés lorsque l'instance a été initialisée par la commande initdb. Aucune de ces options n'est active par défaut. Le paramètre full_page_writes doit lui aussi être activé. Il l'est par défaut.
![[Avertissement]](../images/warning.png)
Si pg_rewind échoue lors du traitement, le répertoire des données de la cible a de forte chance de ne pas être dans un état récupérable. Dans de tels cas, il est recommandé de réaliser une nouvelle sauvegarde.
pg_rewind échouera immédiatement s'il trouve des fichiers sur lesquels il ne peut pas écrire. Ceci peut arriver par exemple quand les serveurs source et cible utilisent la même correspondance de fichier pour les clés et certificats SSL en lecture seule. Si de tels fichiers sont présents sur le serveur cible, il est recommander de les supprimer avant d'exécuter pg_rewind. Après son exécution, certains de ces fichiers pourront être copiés de la source, auquel cas il pourrait être nécessaire de copier les données et de restaurer l'ensemble de liens utilisés avant l'opération.
pg_rewind accepte les arguments suivants en ligne de commande :
Cette option définit le répertoire de données cible qui va être synchronisé avec le répertoire source. L'instance cible doit avoir été arrêtée proprement avant de lancer pg_rewind
Cette option définit le répertoire de données source qui va être synchronisé avec le répertoire cible. Si cette option est utilisée, l'instance source doit être arrêtée proprement.
Définit une chaine de connexion libpq permettant d'accéder à l'instance PostgreSQL™ source de façon à pouvoir la synchroniser avec la cible. Cette connexion est une simple connexion (une connexion type réplication n'est pas nécessaire) avec un accès super-utilisateur. L'instance doit être opérationnelle et ne doit pas être en mode de restauration (recovery).
Réalise toutes les opérations sans modifier le répertoire cible.
Permet d'activer les traces. Activer cette option vous fournira les informations au fil de l'eau sur l'avancée de la copie des données depuis l'instance source.
Affiche les détails de la sortie debug, ce qui est surtout utile aux développeurs qui corrigent pg_rewind.
Affiche les informations concernant la version, puis quitte.
Affiche l'aide, puis quitte.
Lorsque l'option --source-server est utilisée, pg_rewind utilise aussi les variables d'environnement supportées par la bibliothèque libpq (voir Section 31.14, « Variables d'environnement »).
Lors de l'exécution de pg_rewind sur une instance en ligne comme source récemment promue, il est nécessaire d'exécuter un CHECKPOINT après la promotion pour que son fichier de contrôle reflète des informations de timeline à jour, qui est utilisé par pg_rewind pour vérifier si l'instance cible peut être rembobiné en utilisant l'instance source désignée.
L'idée de base est de copier de l'ancienne vers la nouvelle instance l'ensemble des blocs de données à l'exception de ceux dont on sait qu'ils n'ont pas été modifiés.
On parcourt les fichiers WAL de l'ancienne instance, à partir du dernier checkpoint et avant le moment où la nouvelle instance à bifurqué vers une nouvelle timeline par rapport à l'ancienne instance. Pour tous les enregistrements contenus dans les fichiers WAL de l'ancienne instance, un tag est posé sur chaque bloc de données associé. Cela compose une liste de tous les blocs de données modifiés de l'ancienne instance, après que la nouvelle instance ait basculé.
On copie l'ensemble de ces blocs modifiés de la nouvelle instance vers l'ancienne instance.
On copie l'ensemble des autres fichiers tels que les fichiers clog et les fichiers de configuration depuis la nouvelle instance vers l'ancienne instance, excepté les fichiers des bases.
On applique les fichiers WAL récupérés de la nouvelle instance, en commencant à partir du checkpoint créé lors de la bascule. (Au sens strict, pg_rewind n'applique pas les fichiers WAL, il crée juste un fichier backup_label qui stipule à quel moment la nouvelle instance a été démarrée. Au démarrage de l'instance que l'on remet à jour, elle partira de ce checkpoint et appliquera tous les fichiers WAL requis.)
