Mise en place sauvegarde pgBackRest sur hot_standby

Les utilisateurs n'aiment pas perdre de données
Répondre
jeykey
Messages : 2
Enregistré le : jeu. 7 nov. 2019 17:52

Mise en place sauvegarde pgBackRest sur hot_standby

Message par jeykey » jeu. 7 nov. 2019 18:01

Bonjour,

Je souhaite mettre en place une sauvegarde de la base qui tourne sur un serveur pg10 avec pgBackRest. Or celui-ci est un primaire qui réplique vers un standby. La config du stanza implique la modification de l'archive_command avec le mot clé "pgbackrest --stanza=..." or celui-ci (l'archive_command) est déjà utilisé pour l'archivage (+ la compression) de mes WAL pour le serveur standby.
Savez-vous s'il existe un moyen de procéder tout en gardant le "wal_level = hot_standby" :?:

Merci pour la réponse
JK

Phil
Administrateur du site
Messages : 248
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Re: Mise en place sauvegarde pgBackRest sur hot_standby

Message par Phil » ven. 8 nov. 2019 14:43

Merci pour la question !

Avec Oracle Dataguard, la primaire envoie les infos vers la standby via log_archive_dest ou autre mais, en théorie, avec PostgreSQL c'est la standby qui demande les infos à la primaire : https://www.postgresql.org/docs/10/stan ... tings.html . L'archive_command de la primaire n'est pas utile pour envoyer les WAL à la standby.

L'outil de sauvegarde vient en complément, il permet en fait d'avoir 2 canaux pour les informations de journalisation.
Je n'ai pas encore utilisé pgBackRest en environnement primaire/standby mais j'ai beaucoup utilisé Barman dans ce cas et les possibilités doivent être identiques.

Voici un schéma possible :
exemple_pra.jpg
exemple_pra.jpg (67.29 Kio) Vu 95 fois
L'idée est d'archiver les WAL normalement vers Barman (pgBackRest dans votre cas) via archive_command, qu'il y ait une standby ou non. Une standby peut d'ailleurs aussi archiver les informations de journalisation avec archive_mode = always.

La standby, elle, demande les infos de journalisation dont elle a besoin via 2 chemins (paramétrage dans recovery.conf avec pg 10) :
- Le streaming des WAL depuis la primaire : primary_conninfo = ...
- Le repository Barman en cas de besoin : restore_command = 'barman-wal-restore -U barman XXXXX XXXX %f %p' (=> à remplacer par la stanza pgBackRest primaire dans votre cas)

L'intérêt : la primaire ne se préoccupe pas de la standby et n'a pas à converser les WAL au risque de saturer l'espace. Si la standby est trop en retard (interruption réseau ou autre), Barman (ou pgBackRest) les a de toute façon encore (évidemment tout de même dans la limite de la fenêtre de recover...).
C'est une config quasi sans entretien une fois qu'elle est en place.

Il doit être tout à fait possible de faire la même chose avec pgBackRest, je publierai un exemple sur le site prochainement.
Cdlt. Phil - pgphil.ovh

jeykey
Messages : 2
Enregistré le : jeu. 7 nov. 2019 17:52

Re: Mise en place sauvegarde pgBackRest sur hot_standby

Message par jeykey » ven. 8 nov. 2019 16:15

Merci pour la réponse (et le schema) !
Donc si je comprends bien je dois dans tous les cas repenser mon archivage WAL (et par conséquence mon restore_command)
Le truc c'est que mes WAL archivés sont stockés sur un autre FS et sont fréquemment utilisés pour rattraper le retard du standby.
Si je me base sur le schema, j'aurai les WAL ET les sauvegardes sur le même FS/serveur. Ça n'est pas un peu limite en terme de sécurité des données ?
Sur le schema le standby archive aussi ses WAL en continu (ou uniquement en cas de bascule en primaire ?) ?

Phil
Administrateur du site
Messages : 248
Enregistré le : mar. 1 sept. 2015 00:38
Localisation : France
Contact :

Re: Mise en place sauvegarde pgBackRest sur hot_standby

Message par Phil » ven. 8 nov. 2019 17:14

Donc si je comprends bien je dois dans tous les cas repenser mon archivage WAL (et par conséquence mon restore_command)
Idéalement, oui. Vous pourriez être tenté de créer un script maison à passer à archive_command pour garder cette config "Oracle like" et gérer à la fois l'envoi vers pgBackRest et vers la standby mais maintenir de tels scripts n'est pas recommandé si on peut s'en passer.
Si je me base sur le schema, j'aurai les WAL ET les sauvegardes sur le même FS/serveur
Sur le schéma, les serveurs Barman et PostgreSQL sont distincts. Il est possible d'archiver à distance vers une stanza pgBackRest comme ça l'est avec Barman. La seule restriction est qu'il n'est pas actuellement possible de faire du streaming WAL vers pgBackRest alors que c'est possible avec Barman.
Mais, même si la sauvegarde pgBackRest est sur le même serveur/stockage que le cluster primaire, ce n'est pas forcément un problème s'il existe une standby et si cette standby est sur un stockage et un serveur distincts du serveur PostgreSQL primaire.
Sur le schema le standby archive aussi ses WAL en continu (ou uniquement en cas de bascule en primaire ?) ?
La standby récupère les infos de journalisation depuis la primaire et/ou le serveur pgBackRest. Le schéma est basé sur une vieille version de PostgreSQL qui ne permettait pas d'archiver depuis une standby. Mais vous utilisez une version assez récente, PostgreSQL 10. Dans cette version, la standby peut elle-même faire l'objet de sauvegardes et archiver les WAL qu'elle reçoit si archive_mode=always. Au final, on obtient un vrai miroir.
Extrait de la doc traduite en français (https://docs.postgresql.fr/10/runtime-config-wal.html) :

archive_mode (enum)

Quand archive_mode est activé, les segments WAL remplis peuvent être archivés en configurant archive_command. En plus de off, pour désactiver, il y a deux autres modes : on, et always. Lors du fonctionnement normal du serveur, il n'y a pas de différences entre les deux modes, mais lorsqu'il est positionné sur always, l'archiveur des WAL est aussi activé lors d'un rejeu des archives et en mode standby. Dans le mode always, tous les fichiers restaurés à partir de l'archive ou envoyés lors de la réplication en continue seront archivés (à nouveau). Voir Section 26.2.9, « Archivage continu côté standby » pour des détails.

Le truc c'est que mes WAL archivés sont stockés sur un autre FS et sont fréquemment utilisés pour rattraper le retard du standby.
La standby peut demander les infos de journalisation à la primaire via streaming des WAL mais aussi à la stanza pgBackRest du cluster primaire. La stanza pgBackRest doit permettre de gérer pas mal de retard de la standby.
pgBackRest est, dans la version actuelle 2.x, un poil moins simple à configurer que Barman puisqu'il n'y a pas de notion de fenêtre de recover mais il est tout à fait possible de gérer N jours de recover, donc de retard possible de la standby, en choisissant le niveau de redondance.
Cdlt. Phil - pgphil.ovh

Répondre