PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Barman 2.11 :barman-cloud-restore et barman-cloud-wal-restore

Grâce aux nouveaux utilitaires barman-cloud-restore et barman-cloud-wal-restore introduit dans Barman 2.11 , il est maintenant possible d'exécuter la restauration d'une instance PostgreSQL à l'aide d'une sauvegarde complète précédemment exécutée à l'aide de barman-cloud-wal-archive et barman-cloud-backup commandes. Découvrons ensemble comment mettre cela en place dans l'article suivant.


Il convient de noter que dans Barman 2.11, tous les utilitaires cloud pour Barman se trouvent désormais dans un package séparé appelé barman-cli-cloud .

Exigences

1. barman-cli-cloud paquet
2. Une instance PostgreSQL
3. Un compartiment AWS S3
4. Une deuxième machine virtuelle où exécuter la restauration

Dans cet article, nous allons tester barman-cli-cloud fonctionnalités dans une machine virtuelle avec Debian Buster et PostgreSQL 12. Afin de suivre correctement les instructions contenues dans cet article, nous supposons également que vous avez :

  • configuré Postgres pour archiver les fichiers WAL dans un compartiment S3 existant à l'aide de barman-cloud-wal-archive
  • a exécuté une sauvegarde et l'a envoyée au même compartiment S3 via barman-cloud-backup

Vous pouvez facilement y parvenir en suivant les instructions contenues dans ces articles de blog précédents :

  • Barman Cloud – Partie 1 :Archive WAL
  • Barman Cloud – Partie 2 :Sauvegarde dans le cloud

Configurer le serveur de récupération

En conséquence, nous avons un compartiment S3 sur AWS nommé barman-s3-test qui contient déjà les fichiers WAL et la sauvegarde archivée via barman-cloud-wal-archive et barman-cloud-backup outils, nous devons maintenant configurer correctement un serveur qui sera l'hôte pour la récupération de l'instance PostgreSQL.

1. Installez PostgreSQL 12 depuis le dépôt officiel PGDG

2. Installez le référentiel public 2ndQuadrant

3. Installez le barman-cli-cloud paquet :

[email protected] :~# apt [email protected] :~# apt install barman-cli-cloud

4. Installez awscli paquet :

[email protected] :~# apt install awscli

5. Configurez les informations d'identification AWS avec l'outil awscli en tant qu'utilisateur postgres :

[email protected] :~$ aws configure --profile barman-cloudAWS Access Key ID [Aucun] :AKI***************** Clé d'accès secrète AWS [Aucun ] :**************************************** Nom de région par défaut [Aucun] :eu -west-1Format de sortie par défaut [Aucun] :json

Exécuter la procédure de restauration

Maintenant que le serveur de récupération est correctement configuré, nous sommes prêts à démarrer la procédure de restauration.

Barman 2.11 introduit la barman-cloud-backup-list commande qui permet de récupérer des informations sur les sauvegardes faites avec barman-cloud-backup :

[email protected] :~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12Backup ID End Time Begin Wal20200713T120856 2020-07-13 12:09 :05 0000000100000000000000C

Nous sommes maintenant prêts à exécuter la restauration en utilisant le barman-cloud-restore commande :

[email protected] :~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/ 

 Une fois la restauration terminée avec succès, nous pouvons vérifier le contenu du répertoire PGDATA :
 
[email protected] :~$ ls /var/lib/postgresql/12/main/PG_VERSION global pg_hba.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.confbackup_label pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal pg_dynshmbase pg_replslot pg_stat pg_tblspc pg_xact
 

 Maintenant, pour être sûr que le processus de restauration a fonctionné correctement, nous devons démarrer l'instance PostgreSQL récupérée et vérifier que tout fonctionne comme prévu. Ce processus nécessite quelques étapes supplémentaires.
 

 Tout d'abord, puisque nous sommes sur un système Debian, nous devons copier les fichiers contenant la configuration PostgreSQL sous le /etc/postgresql/12/main/ répertoire :
 
[email protected] :~$ cp /var/lib/postgresql/12/main/postgresql.conf /etc/postgresql/12/main/[email protected] :~$ cp /var/lib/postgresql /12/main/pg_hba.conf /etc/postgresql/12/main/[email protected]:~$ cp /var/lib/postgresql/12/main/pg_ident.conf /etc/postgresql/12/main/ 

 Deuxièmement, créez le recovery.signal fichier :
 
[email protected] :~$ touch /var/lib/postgresql/12/main/recovery.signal
 

 Ensuite, désactivez la archive_command pour empêcher l'instance récupérée d'écrire dans le même bucket que l'instance d'origine :
 
[email protected] :~$ echo \"archive_command ='cd .'\">> /etc/postgresql/12/main/postgresql.conf
 

 Après cela, vous devez configurer PostgreSQL pour récupérer les fichiers WAL de la dernière chronologie disponible à partir du compartiment S3 en utilisant le barman-cloud-wal-restore dans la restore_command :
 
[email protected] :~$ echo \"restore_command ='barman-cloud-wal-restore --profile barman-cloud s3://barman-s3-test pg12 %f %p'\">> / etc/postgresql/12/main/[email protected] :~$ echo \"recovery_target_timeline ='latest'\">> /etc/postgresql/12/main/postgresql.conf
 

 IMPORTANT  :Avant de continuer, assurez-vous que l'instance PostgreSQL n'est pas en cours d'exécution et que le répertoire de destination (le répertoire de données PostgreSQL par défaut) est vide.
 

 Enfin, nous sommes prêts à démarrer la nouvelle instance récupérée :
 
[email protected] :~# systemctl restart [email protected]
 

 Génial! Comme nous pouvons le voir dans le journal PostgreSQL, les fichiers WAL sont récupérés à partir du compartiment S3 et l'instance a été correctement démarrée :
 
[email protected] :~$ less /var/log/postgresql/postgresql-12-main.log...2020-07-13 12:43:25.093 UTC [9458] LOG :démarrage de PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) sur x86_64-pc-linux-gnu, compilé par gcc (Debian 8.3.0-6) 8.3.0, 64-bit2020-07-13 12:43:25.093 UTC [9458] LOG :écoute sur l'adresse IPv4 "127.0.0.1", port 54322020-07-13 12:43:25.095 UTC [9458] LOG :écoute sur le socket Unix "/var/run/postgresql/.s.PGSQL.5432"2020-07- 13 12:43:25.111 UTC [9459] LOG :le système de base de données a été interrompu ; connu pour la dernière fois le 2020-07-13 12:08:56 UTC2020-07-13 12:43:25.508 UTC [9459] LOG :démarrage de la récupération de l'archive2020-07-13 12:43:26.010 UTC [9459] LOG :journal restauré fichier "00000001000000000000000C" de archive2020-07-13 12:43:26.052 UTC [9459] LOG :la reprise commence à 0/C0000282020-07-13 12:43:26.054 UTC [9459] LOG :état de récupération cohérent atteint à 0/C0001382020 -07-13 12:43:26.054 UTC [9458] LOG :le système de base de données est prêt à accepter les connexions en lecture seule. 13 12:43:26.823 UTC [9459] LOG :refait à 0/D0001B02020-07-13 12:43:27.242 UTC [9459] LOG :fichier journal restauré "0000000100000000000000D" de l'archive2020-07-13 12:43:27.592 UTC [9459] LOG :ID de la nouvelle chronologie sélectionnée :22020-07-13 12:43:27.644 UTC [9459] LOG :récupération de l'archive terminée2020-07-13 12:43:27.979 UTC [9458] LOG :le système de base de données est prêt à accepter les connexions
 
Conclusion
 

 Comme d'habitude avec toute nouvelle version de Barman, nous recommandons à chacun de mettre à jour son système avec la dernière version. Une liste complète des modifications et des corrections de bogues est disponible ici.
 

 Veuillez noter que si vous utilisez déjà barman-cloud-wal-archive ou barman-cloud-backup installé via le package RPM/Apt et que vous mettez à jour votre système, vous devez installer le barman-cli-cloud emballer. Cela est dû au fait qu'avec la version Barman 2.11, tous les outils liés au cloud font partie du barman-cli-cloud package comme expliqué au début de l'article.
 

 Les prochaines versions de Barman pourraient améliorer la convivialité et les capacités d'automatisation de la commande recover, par exemple en préparant un recovery.conf ou recovery.signal fichier comme le fait le vrai Barman.