Dankzij de nieuwe hulpprogramma's barman-cloud-restore en barman-cloud-wal-restore geïntroduceerd in Barman 2.11 , is het nu mogelijk om het herstel van een PostgreSQL-instantie uit te voeren met behulp van een volledige back-up die eerder is uitgevoerd met barman-cloud-wal-archive en barman-cloud-backup commando's. Laten we samen ontdekken hoe we dit kunnen implementeren in het volgende artikel.
Het is vermeldenswaard dat in Barman 2.11 alle cloudhulpprogramma's voor Barman zich nu in een apart pakket bevinden met de naam barman-cli-cloud .
Vereisten
1. barman-cli-cloud pakket
2. Een PostgreSQL-instantie
3. Een AWS S3-emmer
4. Een tweede virtuele machine waar het herstel kan worden uitgevoerd
In dit artikel testen we barman-cli-cloud functionaliteiten in een virtuele machine met Debian Buster en PostgreSQL 12. Om de instructies in dit artikel correct te volgen, gaan we er ook vanuit dat u beschikt over:
- Postgres geconfigureerd om WAL-bestanden te archiveren naar een bestaande S3-bucket met behulp van
barman-cloud-wal-archive - een back-up uitgevoerd en naar dezelfde S3-bucket verzonden via
barman-cloud-backup
U kunt dit gemakkelijk bereiken door de instructies in deze vorige blogartikelen te volgen:
- Barman Cloud – Deel 1:WAL-archief
- Barman Cloud – Deel 2:Cloudback-up
De herstelserver instellen
Als resultaat hebben we een S3-bucket op AWS met de naam barman-s3-test die al de WAL-bestanden en back-up bevat die zijn gearchiveerd via barman-cloud-wal-archive en barman-cloud-backup hulpprogramma's, moeten we nu een server correct configureren die de host zal zijn voor het herstel van de PostgreSQL-instantie.
1. Installeer PostgreSQL 12 vanuit de officiële PGDG-repository
2. Installeer de 2ndQuadrant Public repository
3. Installeer de barman-cli-cloud pakket:
[email protected]:~# apt update [email protected]:~# apt install barman-cli-cloud
4. Installeer awscli pakket:
[email protected]:~# apt install awscli
5. Configureer AWS-inloggegevens met de awscli-tool als de postgres-gebruiker:
[email protected]:~$ aws configure --profile barman-cloud AWS Access Key ID [None]: AKI***************** AWS Secret Access Key [None]: **************************************** Default region name [None]: eu-west-1 Default output format [None]: json
Voer de herstelprocedure uit
Nu de herstelserver correct is geconfigureerd, zijn we klaar om de herstelprocedure te starten.
Barman 2.11 introduceert de barman-cloud-backup-list commando waarmee u informatie kunt ophalen over de back-ups die zijn gemaakt met barman-cloud-backup :
[email protected]:~$ barman-cloud-backup-list \ --profile barman-cloud \ s3://barman-s3-test pg12 Backup ID End Time Begin Wal 20200713T120856 2020-07-13 12:09:05 00000001000000000000000C
We zijn nu klaar om het herstel uit te voeren met behulp van de barman-cloud-restore commando:
[email protected]:~$ barman-cloud-restore \ --profile barman-cloud \ s3://barman-s3-test \ pg12 20200713T120856 \ /var/lib/postgresql/12/main/
Zodra het herstel succesvol is beëindigd, kunnen we de inhoud van de PGDATA-map controleren:
[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.conf backup_label pg_commit_ts pg_ident.conf pg_notify pg_snapshots pg_subtrans pg_wal postgresql.conf base pg_dynshmem pg_logical pg_replslot pg_stat pg_tblspc pg_xact
Om er zeker van te zijn dat het herstelproces correct werkte, moeten we de herstelde PostgreSQL-instantie starten en controleren of alles werkt zoals verwacht. Dit proces vereist enkele extra stappen.
Ten eerste moeten we, aangezien we op een Debian-systeem werken, de bestanden met de PostgreSQL-configuratie kopiëren onder de /etc/postgresql/12/main/ map:
[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/
Ten tweede, maak het recovery.signal bestand:
[email protected]:~$ touch /var/lib/postgresql/12/main/recovery.signal
Schakel vervolgens de archive_command . uit om te voorkomen dat de herstelde instantie in dezelfde bucket schrijft als de oorspronkelijke instantie:
[email protected]:~$ echo \"archive_command = 'cd .'\" >> /etc/postgresql/12/main/postgresql.conf
Daarna moet u PostgreSQL configureren om de WAL-bestanden van de nieuwste beschikbare tijdlijn uit de S3-bucket op te halen met behulp van de barman-cloud-wal-restore in de 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/postgresql.conf [email protected]:~$ echo \"recovery_target_timeline = 'latest'\" >> /etc/postgresql/12/main/postgresql.conf
BELANGRIJK :Voordat u doorgaat, moet u ervoor zorgen dat de PostgreSQL-instantie niet actief is en dat de doelmap (de standaard PostgreSQL-datadir) leeg is.
Eindelijk zijn we klaar om de nieuwe herstelde instantie te starten:
[email protected]:~# systemctl restart [email protected]
Super goed! Zoals we kunnen zien in het PostgreSQL-logboek, worden WAL-bestanden hersteld van de S3-bucket en is de instantie correct gestart:
[email protected]:~$ less /var/log/postgresql/postgresql-12-main.log ... 2020-07-13 12:43:25.093 UTC [9458] LOG: starting PostgreSQL 12.3 (Debian 12.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit 2020-07-13 12:43:25.093 UTC [9458] LOG: listening on IPv4 address "127.0.0.1", port 5432 2020-07-13 12:43:25.095 UTC [9458] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2020-07-13 12:43:25.111 UTC [9459] LOG: database system was interrupted; last known up at 2020-07-13 12:08:56 UTC 2020-07-13 12:43:25.508 UTC [9459] LOG: starting archive recovery 2020-07-13 12:43:26.010 UTC [9459] LOG: restored log file "00000001000000000000000C" from archive 2020-07-13 12:43:26.052 UTC [9459] LOG: redo starts at 0/C000028 2020-07-13 12:43:26.054 UTC [9459] LOG: consistent recovery state reached at 0/C000138 2020-07-13 12:43:26.054 UTC [9458] LOG: database system is ready to accept read only connections 2020-07-13 12:43:26.469 UTC [9459] LOG: restored log file "00000001000000000000000D" from archive 2020-07-13 12:43:26.823 UTC [9459] LOG: redo done at 0/D0001B0 2020-07-13 12:43:27.242 UTC [9459] LOG: restored log file "00000001000000000000000D" from archive 2020-07-13 12:43:27.592 UTC [9459] LOG: selected new timeline ID: 2 2020-07-13 12:43:27.644 UTC [9459] LOG: archive recovery complete 2020-07-13 12:43:27.979 UTC [9458] LOG: database system is ready to accept connections
Conclusie
Zoals gebruikelijk bij elke nieuwe release van Barman, raden we iedereen aan zijn systemen bij te werken naar de nieuwste versie. Een volledige lijst met wijzigingen en bugfixes is hier beschikbaar.
Houd er rekening mee dat als u al gebruikmaakt van barman-cloud-wal-archive of barman-cloud-backup geïnstalleerd via RPM/Apt-pakket en u bent uw systeem aan het upgraden, moet u de barman-cli-cloud installeren pakket. Dit komt door het feit dat met de Barman 2.11-release alle cloudgerelateerde tools deel uitmaken van de barman-cli-cloud pakket zoals uitgelegd aan het begin van het artikel.
De volgende versies van Barman kunnen de bruikbaarheid en automatiseringsmogelijkheden van het herstelcommando verbeteren, bijvoorbeeld door een recovery.conf voor te bereiden. of recovery.signal bestand zoals de echte Barman dat doet.