Familiarité avec pg_probackup. La seconde partie

Nous continuons à nous familiariser avec l'outil pg_probackup .



Dans la première partie, nous avons installé pg_probackup, créé et configuré une instance, effectué deux sauvegardes - complète et incrémentielle en mode DELTA, appris comment afficher et modifier la configuration de l'instance. Nous avons obtenu une liste de sauvegardes, écrit un script (bkp_base.sh) qui sauvegarde le cluster et envoie les résultats de la dernière opération de sauvegarde au système de surveillance. Aujourd'hui, nous aborderons des tâches non moins intéressantes.

Problème 2

Étant donné: Nous avons deux serveurs, sur le premier nous avons notre base de données (hostname srv_db1, user postgres), et sur le second nous stockerons des sauvegardes (hostname srv_bkp, user backup_user). Mais en plus des sauvegardes sur le même serveur, nous stockerons des copies des journaux de pré-enregistrement afin de pouvoir restaurer à un moment arbitraire (récupération ponctuelle) au cours des 3 derniers jours.



Solution:



afin de pouvoir restaurer au point sélectionné dans le temps (point de restauration), nous devons avoir une sauvegarde effectuée avant le point de restauration, ainsi que tous les fichiers WAL depuis le moment où la sauvegarde a commencé jusqu'au point de restauration.



Nous avons déjà des sauvegardes, il reste à configurer l'archivage WAL sur srv_bkp.

Connectez-vous à srv_db1 par l'utilisateur postgres et exécutez les commandes suivantes:

ssh-keygen -t rsa
ssh-copy-id backup_user@srv_bkp

Modifions le fichier ~ / .ssh / autorized_keys en srv_bkp:

command="pg_probackup-12 agent" ssh-rsa AAAA....

De retour à srv_db1, vous devez activer le mode archive (archive_mode) et configurer le paramètre archive_command. Il contient une commande pour sauvegarder un segment WAL complet.

psql -c 'show archive_mode'

s'il est revenu, passez à on

psql -c 'alter system set archive_mode = on'

Pour que le changement s'applique, vous devez redémarrer PostgreSQL, mais pour l'instant nous reporterons cette action et configurerons un paramètre supplémentaire.



Si le flux de fichiers WAL est suffisamment volumineux, le serveur de sauvegarde peut bientôt manquer d'espace, nous pouvons donc insérer l'option --compress dans la ligne archive_command, puis les fichiers journaux seront compressés avant d'être envoyés à srv_bkp. Et nous n'aurons pas à nous soucier du fait que ces fichiers devront être décompressés séparément lors de la restauration - pg_probackup peut fonctionner avec des fichiers compressés.

alter system set archive_command = 'pg_probackup-12 archive-push -B /home/backup_user/backup_db --instance=db1 --wal-file-path=%p --wal-file-name=%f --remote-host=srv_bkp --remote-user=backup_user --compress';

Vous pouvez maintenant redémarrer.



Ce que nous avons fait dans la première tâche s'appelle une sauvegarde hors ligne. Il est appelé ainsi car une telle copie contient tous les fichiers WAL nécessaires à sa restauration. Dans la tâche actuelle, nous passons des copies hors ligne aux copies d'archive, ces copies ne contiennent pas les journaux nécessaires à l'intérieur, mais cela n'a pas d'importance, car nous allons enregistrer tous les fichiers WAL dont nous avons besoin dans une archive. Lors de la restauration à partir de copies de sauvegarde, les fichiers WAL seront copiés à partir de l'archive.



Étant donné que dans la situation considérée, nous passons des sauvegardes hors ligne (faites en mode flux) à archivées (en mode archive), une situation peut se produire dans laquelle nous avons fait une copie alors que le mode archive n'était pas encore activé, après quoi certains des segments WAL sont déjà apparus supprimé. Cela signifie que la première sauvegarde après le passage en mode archive ne peut pas être effectuée en mode PAGE, car le segment de WAL dans l'archive entre le passé et la copie actuelle peut ne pas être complet.



Faisons cela en utilisant le script créé dans la première tâche:

./bkp_base.sh DELTA

Ensuite, nous créerons notre première sauvegarde en mode PAGE

./bkp_base.sh PAGE

Permettez-moi de vous rappeler qu'il existe trois modes incrémentiels disponibles: PAGE, DELTA et PTRACK. Ils diffèrent les uns des autres dans la manière d'obtenir les informations nécessaires sur les pages modifiées:

• DELTA — ,
• PAGE — WAL , ,
• PTRACK — - Block Change Tracking Oracle — , . ( ..). , .

Et maintenant, réfléchissons, la copie de sauvegarde, pour pouvoir récupérer à partir d'elle, a besoin des fichiers WAL créés lors de la création de la sauvegarde. Ceux. si nous faisons une sauvegarde incrémentielle pendant 30 minutes et pendant ces 30 minutes, 10 Go de WAL ont été créés, alors seuls ces 10 Go sont nécessaires pour que nous puissions en récupérer de manière cohérente. Tous les autres fichiers WAL sont nécessaires uniquement à des fins de récupération ponctuelle.



La tâche a indiqué que nous souhaitons pouvoir récupérer à tout moment au cours des 3 derniers jours. Autrement dit, tous les WAL pour cette période doivent être sauvegardés, en plus, il est nécessaire de sauvegarder tous les WAL nécessaires à la restauration à partir des sauvegardes précédentes, mais nous n'avons pas besoin de stocker tous les autres fichiers WAL!



Et, si nous pouvons utiliser la commande find pour supprimer les WAL obsolètes, en y ajoutant mtime et -exec rm {}, alors déterminer quel segment WAL est nécessaire pour restaurer de manière cohérente une sauvegarde particulière n'est pas une tâche facile. C'est bien que les développeurs aient réfléchi à cela et aient ajouté le paramètre --wal-depth, avec lequel vous pouvez définir la profondeur de stockage WAL, calculée dans les sauvegardes.



Il peut être décrit schématiquement comme suit:







Veuillez noter qu'il est maintenant quelque part au milieu du samedi, ce qui signifie que nous pouvons supprimer tous les fichiers WAL qui ne sont pas nécessaires pour restaurer les sauvegardes de plus de trois jours (couleur marron sur le graphique). Les WAL qui sont encore nécessaires sont surlignés en jaune. Ici, une question logique peut se poser - mais après tout, c'est déjà le milieu du samedi, ce qui signifie que certains des journaux du matin créés le mercredi ne sont plus nécessaires et peuvent être supprimés. Oui, c'est le cas, et vous pouvez configurer la suppression des WAL en excès au moins toutes les minutes, mais dans notre article, nous supprimerons les journaux avec la création de sauvegardes, donc malgré le fait qu'ils ne relèvent plus de la politique de rétention, ils seront supprimés lors de la création de la prochaine sauvegarde. ...



Changer les paramètres de l'instance db1 - ajouter la durée de vie des fichiers WAL

pg_probackup set-config --instance db1 --wal-depth=3

Vérifions que les paramètres ont été appliqués:

pg_probackup show-config --instance=db1 | grep wal-depth

Ajoutez l'indicateur --delete-wal à la commande backup dans le script bkp_base.sh , et supprimez également la clé --stream, car nous passons des sauvegardes hors ligne aux sauvegardes archivées

pg_probackup backup --instance=db1 -j 2 --progress -b $1 --compress --delete-expired --delete-wal

Pour le moment, nous avons configuré la création de sauvegardes d'archives sur un serveur séparé. En outre, des fichiers journaux sont ajoutés ici, ce qui nous donne la possibilité d'utiliser la récupération non seulement pour une sauvegarde spécifique, mais également pour effectuer une récupération à un moment donné - une récupération à un moment précis.



Puisque nous avons maintenant une archive de fichiers WAL, nous pouvons utiliser le mode PAGE pour créer des sauvegardes incrémentielles, laissez-moi vous rappeler que dans ce mode, les changements par rapport à la sauvegarde précédente ne sont pas calculés par des fichiers de données, mais par WAL accumulés depuis la sauvegarde précédente.



PS À des fins éducatives uniquement! Créons une table dans la base de données sur le serveur srv_db1:

psql -c 'create table timing(time_now timestamp with time zone)'

Ensuite, écrivez la ligne suivante dans crontab:

* * * * * psql -c 'insert into timing(select now())'

Chaque minute, des informations sur l'heure actuelle seront enregistrées dans la base de données, ces informations nous seront utiles lors de la restauration à un moment donné.

Problème 3

Étant donné:



Nous avons deux serveurs, sur le premier nous avons notre base de données (hostname srv_db1, user postgres), sur le second stocke les sauvegardes archivées et les fichiers WAL (hostname srv_bkp, user backup_user). Un autre serveur srv_db2 apparaît dans notre environnement (user postgres), sur lequel nous devrons déployer une réplique de notre cluster et reconfigurer pg_probackup pour qu'il prenne des sauvegardes depuis la réplique.



Décision:



Internet regorge de descriptions sur la façon de créer des répliques dans PostgreSQL, il vous suffit de conduire "créer une réplique dans PostgreSQL" dans le moteur de recherche - choisissez, je ne veux pas! Il existe de la documentation, des articles et même des didacticiels vidéo. Et toutes ces méthodes sont bonnes, mais elles ne tiennent généralement pas compte du fait que nous avons déjà des sauvegardes. Nous voulons créer une réplique à l'aide d'une sauvegarde, nous supprimons donc la charge de lecture du maître. Autrement dit, notre serveur de production ne sera pas conscient que quelque part à côté de lui, une réplique est en cours de création (ceci, bien sûr, avec des réservations - ici, l'emplacement de réplication devra être créé et les droits d'accès enregistrés, mais pendant que nous créons une réplique, aucune charge supplémentaire sur le maître ne sera pas).



Nous mettons en place l'accès par clés entre les serveurs srv_bkp et srv_db2, installons PostgreSQL et pg_probackup sur srv_db2 (nous avons tout fait sauf l'installation de PostgreSQL lors de la première tâche, mais si vous avez des questions sur l'installation du SGBD, jetez un œil ici ).



Accédez à srv_db2

ssh-keygen -t rsa
ssh-copy-id backup_user@srv_bkp

Aller à srv_bkp

ssh-copy-id postgres@srv_db2

Allumons notre paranoïaque interne et éditons ~ / .ssh / autorized_keys - insert

command="pg_probackup-12 agent"

avant de nouvelles clés.



L'utilisation de fichiers WAL est beaucoup plus lente que la restauration à partir d'une sauvegarde, alors créons une autre sauvegarde incrémentielle - connectez-vous au serveur srv_bkp en utilisant backup_user et exécutez la commande:

pg_probackup backup --instance=db1 -j 2 --progress -b PAGE --compress

Pourquoi n'avons-nous pas utilisé le script que nous avons créé? Le fait est qu'avant, nous avons ajouté l'option --delete-wal au script, c'est-à-dire qu'après avoir créé cette sauvegarde, nous ne pourrions pas restaurer à un moment donné il y a trois jours. Mais si nous quittons cette sauvegarde, la prochaine sauvegarde effectuée en exécutant notre script ne laissera toujours WAL que pendant les deux derniers jours, c'est-à-dire qu'après la restauration à partir de cette sauvegarde, il est logique de la supprimer.



Nous faisons la récupération:

time pg_probackup restore --instance=db1 -D /var/lib/pgsql/12/data -j 2 --restore-as-replica --progress --remote-proto=ssh --remote-host=srv_db2 --archive-host=srv_bkp --archive-user=backup_user --log-level-console=log --log-level-file=verbose --log-filename=restore_rep.log

Le répertoire / var / lib / pgsql / 12 / data doit être vide, de plus, sur le serveur srv_db1, vous devez apporter des modifications à pg_hba.conf - autoriser l'accès depuis le serveur srv_db2 en utilisant le protocole de réplication.

host    replication     all             srv_db2                 md5

Nous relisons la configuration:

psql -c 'select pg_reload_conf()'

Vérification des fautes de frappe:

psql -c 'select * from pg_hba_file_rules'

créez un fichier ~ / .pgpass sur srv_db2, dans lequel nous spécifions les autorisations de connexion dans srv_db1 mais cette fois avec une base de réplication et démarrez PostgreSQL.

srv_db1:5432:replication:backup:Strong_PWD

Et changeons ses droits en 600:

chmod 600 ~/.pgpass

Nous démarrons le cluster sur srv_db2.



Vérifions que tout fonctionne bien. Nous utiliserons les possibilités suivantes pour cela.



Nous examinons le fichier journal de réplique qu'il contient, quelque part vers la fin, la ligne suivante devrait apparaître:

Database system is ready to accept read only connections

psql -c 'select pg_is_in_recovery()' 

devrait retourner t



Maintenant, créons une plaque t1 sur l'assistant:

srv_db1: psql -c 'create table t1()'

Vérifions s'il est apparu sur la réplique.

srv_db2: psql -c '\d'

La plaque est en place, puis la réplication fonctionne. Nous retirons la plaque sur le maître.

srv_db1: psql -c 'drop table t1'

Bien sûr, sur une vraie base de données, vous devez maintenant créer un emplacement de réplication sur le maître et configurer la réplique pour qu'elle aille au maître via cet emplacement, mais le sujet de notre article ne concerne pas les répliques, mais les sauvegardes, alors continuons.



Donc, la réplique fonctionne pour nous, si nécessaire, nous pouvons passer à la réplique, mais posons-nous une question - pouvons-nous faire mieux?

Bien sûr vous pouvez. Pourquoi devons-nous effectuer des sauvegardes du maître lorsque nous pouvons supprimer la charge de lecture du maître et la transférer vers une réplique?



MISE EN GARDE! LA SURVEILLANCE DU MANQUE DE RÉPLIQUE DOIT ÊTRE SURVEILLÉE, AUTREMENT, IL POURRAIT PRENDRE QUE VOUS NE SAURREZ PAS QUE LA RÉPLIQUE EST EN RETARD ET CONTINUERA À SAUVEGARDER DU LAG DE RÉPLIQUE.



Faisons cela!



Nous apportons des modifications aux paramètres du cluster sur les serveurs srv_db1 et srv_db2:

alter system set archive_timeout=180;
select pg_reload_conf();

Accédez à srv_bkp et modifiez la valeur du paramètre remote-host:

pg_probackup set-config --instance db1 --remote-host=srv_db2

Nous apportons des modifications à .pgpass sur le serveur srv_bkp - ajoutons les chaînes de connexion au serveur srv_db2:

srv_db2:5432:replication:backup:Strong_PWD
srv_db2:5432:backupdb:backup:Strong_PWD

Et essayons de faire une autre sauvegarde.

srv_bkp: ./bkp_base.sh PAGE

On voit que la sauvegarde a fonctionné.



Le problème est résolu!



La partie suivante sera consacrée à la restauration à partir de sauvegardes: nous examinerons différentes options de restauration, apprendrons à restaurer sur une sauvegarde spécifique, à un moment donné, nous familiariserons avec les restaurations partielles et incrémentielles.