pg_rewind — synchronise le répertoire des données de PostgreSQL avec un autre répertoire de données
pg_rewind
[option
...] { -D
| --target-pgdata
} répertoire
{ --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.
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.
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.
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.
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
.
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.
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.