Mise en place sauvegarde pgBackRest sur hot_standby

[jeykey]

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]

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 (84.23 Kio) Vu 262501 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.

[jeykey]

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]

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.

[Phil]

La réponse est valable et testée avec Barman mais pgBackRest présente des limitations, il est impossible de constituer simplement un miroir tel que présenté dans le schéma. pgBackRest ne supporte notamment pas archive_mode = always.
Il doit être possible de bâtir une solution avec rsync pour pallier la limitation. Je suis en train de creuser le sujet mais Barman est tout de même plus simple à utiliser dans ce cas.

-- réponse mise à jour 06/02/2020

J'ai testé la solution et je confirme que Barman est plus simple pour créer une architecture PRA en miroir lorsqu'on dispose de 2 sites indépendants. Les solutions manuelles basées sur rsync ne sont pas assez fiables et je les déconseille.
Il est malgré tout possible d'avoir une stanza sur chaque site mais espérons que pgBackRest supporte archive_mode=always dans le futur.

[Phil]

Nous passons aussi sur pgBackRest et j'ai posé directement la question de la sauvegarde des standby sur le git de pgbackrest. Une réponse claire a été donnée : https://github.com/pgbackrest/pgbackrest/issues/932

En bref, il n'est pas prévu prochainement de supporter archive_mode=always. En attendant, l'idée est donc de récupérer les WAL d'une autre façon. Comme indiqué précédemment et confirmé par le développeur pgBackRest, un script basé sur rsync est sans doute la solution la plus simple.

[Phil]

Vieux sujet mais pgBackRest supporte à présent archive_mode=always.