pg_rewind

» » »

Précédent	Niveau supérieur	Suivant
pg_resetwal	Sommaire	pg_test_fsync

pg_rewind

pg_rewind — synchronise le répertoire des données de PostgreSQL avec un autre répertoire de données

Synopsis

pg_rewind [option...] { -D | --target-pgdata } répertoire { --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.

Après une synchronisation réussie, l'état du répertoire de données cible est analogue à une sauvegarde de base du répertoire source de données. Contrairement à l'exécution d'une sauvegarde de base ou l'utilisation d'un outil comme rsync, pg_rewind ne requiert pas de comparer ou copier les blocs inchangés des relations dans l'instance. Seuls les blocs modifiés de fichiers de relation existante sont copiés ; tous les autres fichiers, incluant tout nouveau fichier de relation, fichier de configuration, et segment WAL, sont copiés en totalité. Ainsi, l'opération de synchronisation est significativement plus rapide que les autres approches si la base de données est volumineuse et que seule une petite fraction de blocs diffère entre les 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_wal. Le point de divergence peut être trouvé soit sur la ligne de temps cible, soit sur la ligne de temps source, soit sur leur ancêtre commun. 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_wal. Dans ce cas, ils peuvent être copiés à la main depuis les fichiers WAL archivés vers le répertoire pg_wal ou être réexécutés par pg_rewind avec l'option -c pour automatiquement les récupérer de l'archive WAL. L'utilisation de pg_rewind n'est pas limitée au failover : un serveur standby peut être promu, écrire quelques transactions, puis transformé de nouveau en standby avec cet outil.

Après avoir exécuté pg_rewind, il est nécessaire que la réapplication des WAL se termine pour que le répertoire de données soit dans un état cohérent. Quand le serveur cible est redémarré, il va entrer en récupération d'archive et rejouer tous les WAL générés sur le serveur source depuis le dernier checkpoint avant le point de divergence. Si certains WAL ne sont plus disponibles sur le serveur source quand pg_rewind a été exécutée, et par conséquent ne peuvent plus être copiés par la session pg_rewind, ils doivent être rendus disponible quand le serveur cible est démarré. Ceci peut être effectué en créant un fichier recovery.signal dans le répertoire de données cible et en configurant un restore_command approprié dans postgresql.conf.

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

Attention : échecs lors du retour en arrière

Si pg_rewind échoue lors du traitement, le répertoire des données de la cible est très probablement dans un état inutilisable. Dans ce cas, réaliser une nouvelle sauvegarde est recommandé.

Comme pg_rewind copie entièrement les fichiers de configuration de la source, il peut être requis de corriger la configuration employée pour la reprise avant de redémarrer le serveur cible, particulièrement si la cible est réintroduite comme un standby de la source. Si vous redémarrez le serveur après que l'opération de synchronisation soit terminée mais sans reprendre la configuration, la cible peut diverger du primaire.

pg_rewind échouera immédiatement s'il trouve des fichiers qu'il ne peut pas modifier. Ceci peut arriver quand les serveurs source et cible utilisent les mêmes emplacements pour les clés et les certificats SSL qui sont habituellement en lecture seule. Si de tels fichiers sont présents sur le serveur cible, il est recommandé de les supprimer avant d'exécuter pg_rewind. Après l'avoir exécuté, certains de ces fichiers devront peut-être être copiés de la source, auquel cas il pourrait être nécessaire de supprimer les données copiées et de restaurer l'ensemble des liens utilisés avant l'exécution de l'outil.

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. Cette option requiert que le serveur source ait été arrêté proprement.
--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 option requiert l'utilisation d'une connexion standard avec un rôle ayant les droits suffisants pour exécuter les fonctions utilisées par pg_rewind sur le serveur source (voir la section Notes pour les détails) ou un rôle superutilisateur.
--no-ensure-shutdown: pg_rewind requiert que le serveur cible soit proprement arrêté avant d'être synchronisé. Par défaut, si le serveur cible n'est pas proprement arrêté, pg_rewind le démarre en mode simple-utilisateur pour effectuer d'abord une récupération après accident, et l'arrête. En utilisant cette option, pg_rewind ignore cela et tombe en erreur immédiatement si le serveur n'est pas proprement stoppé. Les utilisateurs doivent s'attendre à gérer la situation eux-même dans ce cas.
-R --write-recovery-conf: Crée standby.signal et ajoute les paramètres de connexion à postgresql.auto.conf dans le répertoire de sortie. --source-server est obligatoire avec cette option.
-n --dry-run: Réalise toutes les opérations sans modifier le répertoire cible.
-N --no-sync: Par défaut, pg_rewind attendra l'écriture certaine de tous les fichiers sur disque. Cette option permet de forcer le retour de pg_rewind sans attente, ce qui est plus rapide, mais signifie qu'un crash ultérieur du système d'exploitation pourrait laisser le répertoire des données dans un état corrompu. En général, cette option est utile pour des tests, mais ne devrait pas être utilisée pour créer un serveur en production.
-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.
-c --restore-target-wal: Utilise restore_command définie dans la configuration de l'instance cible pour reprendre les fichiers WAL depuis l'archive WAL si ces fichiers ne sont plus disponibles dans le répertoire pg_wal.
--config-file=nom_fichier: Utilise le fichier de configuration du serveur indiqué pour l'instance cible. Ceci affecte pg_rewind quand il utilise en interne la commande postgres pour l'opération sur cette instance (lors de la récupération de restore_command avec l'option -c/--restore-target-wal et quand il force la fin d'une restauration après un crash).
--debug: Affiche les détails de la sortie de débogage, ce qui est surtout utile aux développeurs qui travaillent sur 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 34.15).

La variable d'environnement PG_COLOR indique s'il faut utiliser les couleurs dans les messages de diagnotiques. Les valeurs possibles sont always, auto, never.

Notes

Lors de l'exécution de pg_rewind sur une instance en ligne comme source, un rôle doté des droits suffisants pour exécuter les fonctions utilisées par pg_rewind sur l'instance source peut être utilisé à la place d'un superutilisateur. Voici comment créer ce rôle, nommé ici rewind_user :

CREATE USER rewind_user LOGIN;
GRANT EXECUTE ON function pg_catalog.pg_ls_dir(text, boolean, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_stat_file(text, boolean) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text) TO rewind_user;
GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO rewind_user;

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.

Lors de l'exécution de pg_rewind sur une instance source en ligne qui a été récemment promue, il est nécessaire d'exécution un CHECKPOINT après la promotion pour que le fichier contrôle reflète des informations à jour sur la timeline, informations qui sont utilisées par pg_rewind pour vérifier si l'instance cible peut être traitée en utilisant l'instance source désignée.

Fonctionnement

L'idée de base est de copier toutes les modifications de fichiers au niveau système de fichiers de l'instance source vers l'instance cible :

Parcourir les journaux de transactions de l'instance cible, en commençant du dernier checkpoint avant le moment où l'historique de timeline de l'instance source a dévié de celle de l'instance cible. Pour chaque enregistrement dans les journaux de transactions, enregistrer chaque bloc de données modifié. Ceci a pour résultat une liste de tous les blocs de données modifiés dans l'instance cible, après la séparation avec l'instance source. Si certains fichiers WAL ne sont plus disponibles, essayez de ré-exécuter pg_rewind avec l'option -c pour chercher les fichiers manquants dans l'archive WAL.
Copier tous les blocs modifiés de l'instance source vers l'instance cible, soit en utilisant un accès direct au système de fichiers (--source-pgdata) soit en SQL (--source-server). Les fichiers de relations sont maintenant dans un état équivalent au moment du dernier checkpoint effectué avant le point où les timelines WAL de la source et de la cible divergent, plus l'état actuel sur la source où il existe des blocs modifiés sur la cible après divergence.
Copier tous les autres fichiers, incluant les nouveaux fichiers de relation, les segments WAL, pg_xact, et les fichiers de configuration de l'instance source sur l'instance cible. De manière similaire, les sauvegardes de base, le contenu des répertoires pg_dynshmem/, pg_notify/, pg_replslot/, pg_serial/, pg_snapshots/, pg_stat_tmp/ et pg_subtrans/ sont omis des données copiées depuis le serveur source. Les fichiers backup_label, tablespace_map, pg_internal.init, postmaster.opts, et postmaster.pid et .DS_Store, aussi bien que tous fichiers ou répertoires commençant par pgsql_tmp, sont omis.
Crée un ficher backup_label pour débuter la reprise des WAL au checkpoint créé lors de la bascule et configure le fichier pg_control avec une cohérence minimale du LSN définie comme le résultat de pg_current_wal_insert_lsn() lorsque la synchronisation s'effectue depuis une source activée ou le dernier checkpoint LSN quand la synchronisation s'effectue depuis une source stoppée.
Quand la cible est démarrée, PostgreSQL reprend tous les WAL nécessaires, donnant ainsi un répertoire de données à un état cohérent.