pg_rewind

pg_rewind — synchronise le répertoire des données de PostgreSQL™ avec un répertoire de données dupliqué depuis le premier

Synopsis

pg_rewind [option...] { -D | --target-pgdata } directory { --source-pgdata=répertoire | --source-server=chaine_de_connexion }

Description

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.

Options

pg_rewind accepte les arguments suivants en ligne de commande :

-D répertoire, --target-pgdata=répertoire

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

--source-pgdata=répertoire

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.

--source-server=chaine de connexion

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

-n, --dry-run

Réalise toutes les opérations sans modifier le répertoire cible.

-P, --progress

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.

--debug

Affiche les détails de la sortie debug, ce qui est surtout utile aux développeurs qui corrigent pg_rewind.

-V, --version

Affiche les informations concernant la version, puis quitte.

-?, --help

Affiche l'aide, puis quitte.

Environnement

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

Notes

Fonctionnement

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.

  1. 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é.

  2. On copie l'ensemble de ces blocs modifiés de la nouvelle instance vers l'ancienne instance.

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

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