Indledning
Hvor mange nuværende Barman-brugere har tænkt på at gemme sikkerhedskopier på en fjerndestination i skyen? Hvor mange har tænkt på at tage den sikkerhedskopi direkte fra selve PostgreSQL-serveren?
Nå, siden Barman 2.10 det er nu muligt!
Hvordan?
Lad os opdage det sammen i de følgende artikler.
Krav
De følgende to artikler er beregnet til at være en praktisk introduktion til det nye barman-cloud-wal-archive og barman-cloud-backup værktøjer tilføjet i barman-cli pakke.
Den første del vil dække barman-cloud-wal-archive kommando, mens den anden vil dække barman-cloud-backup kommando.
Læsere har brug for et grundlæggende kendskab til PostgreSQL WAL arkivering og backup metoder og Barman. Det anbefales også, at du er opmærksom på cloud-teknologier til lagringsløsninger som Amazon S3.
WAL-arkiv
Barman har fungeret som et fjerntliggende WAL-arkiv i mange år, og Barman CLI-pakken er designet til at udvide arkiveringspålidelighed og robusthed på PostgreSQL-siden. Faktisk barman-cli leverer scripts som barman-wal-restore tillader en standby-knude at genskabe WAL-filer på en smart og sikker måde fra et Barman-arkiv gennem restore_command parameter i postgresql.auto.conf fil (eller recovery.conf fil indtil PostgreSQL 12), og barman-wal-archive at arkivere WAL-filer fra en masterknude til Barman gennem archive_command parameter konfigureret i postgresql.conf fil.
Cloud WAL-arkiv
Takket være brugernes feedback har Barman-udviklerne introduceret to nye værktøjer i version 2.10 :
barman-cloud-wal-archivebarman-cloud-backup
Version 2.11 vil inkludere to ekstra værktøjer til gendannelse, kaldet barman-cloud-wal-restore og barman-cloud-restore .
Dette indlæg er udelukkende dedikeret til barman-cloud-wal-archive , som kan gemme WAL-filer i skyen, hvilket muliggør flerlagsarkivering med Barman og udvider sikkerhedskopieringspolitikken.
Faktisk barman-cloud-wal-archive kan bruges som et hook-script, der konfigurerer pre_archive_retry_script parameter i Barman, for at kopiere WAL-filer i det konfigurerede skylager, hvilket øger redundansen af arkivet og gør det muligt at vælge en længere opbevaringspolitik end Barman.
Det er ikke alt!
barman-cloud-wal-archive kan erstatte barman-wal-archive kommandoen i archive_command parameter, for direkte at arkivere WAL-filer i skyen i stedet for at kopiere dem til Barman-serveren. På denne måde kan selv en PostgreSQL-klynge, der ikke har en separat dedikeret backup-server, stole på fjernlagringstjeneste til at arkivere WAL-filer.
Hvordan virker det?
Følgende instruktioner er kun til at installere og konfigurere barman-cloud-wal-archive som archive_command i PostgreSQL.
Beslut først, hvor WAL-filer skal arkiveres. I denne artikel vil vi bruge Amazon S3, som i skrivende stund er den eneste understøttede teknologi. Selvom andre teknologier, der understøtter S3-lignende API (Google Cloud, DigitalOcean, Microsoft Azure, osv.) kan arbejde med boto3-biblioteket, er de ikke blevet testet endnu.
Krav
- barman-cli 2.10 (eller nyere)
- Amazon AWS-konto
- awscli
- S3-spand
- En PostgreSQL-instans
I denne artikel vil vi teste Barman CLI i en virtuel maskine med Debian Buster og PostgreSQL 12 som allerede er oppe at køre.
Installation
-
- Installer 2ndQuadrant Public repository
- Installer barman-cli-pakken
[email protected]:~# apt update [email protected]:~# apt install barman-cli
- Installer awscli
[email protected]:~# apt install awscli
Konfiguration og opsætning
Lad os læse manualen:
[email protected]:~$ man barman-cloud-wal-archive [...] SYNOPSIS barman-cloud-wal-archive [OPTIONS] DESTINATION_URL SERVER_NAME WAL_PATH [...] POSITIONAL ARGUMENTS DESTINATION_URL URL of the cloud destination, such as a bucket in AWS S3. For example: s3://BUCKET_NAME/path/to/folder (where BUCKET_NAME is the bucket you have created in AWS). SERVER_NAME the name of the server as configured in Barman. WAL_PATH the value of the `%p' keyword (according to `archive_command'). [...]
Så for at bruge det korrekt skal vi bare konfigurere AWS-legitimationsoplysninger med
awscliværktøj sompostgresbruger, kopiering af adgangsnøgle og hemmelig nøgle, der tidligere er oprettet i IAM-sektionen i AWS-konsollen:[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
Sørg for at have en tilgængelig S3-spand på AWS. Jeg valgte at kalde det
barman-s3-testfor at gøre det klart.
Vi burde være i stand til nu at testebarman-cloud-wal-archivekommando:[email protected]:~$ barman-cloud-wal-archive -t -P barman-cloud s3://barman-s3-test/ pg12 /var/lib/postgresql/12/main/pg_wal/000000010000000000000001 [email protected]:~$ echo $? 0
Afslutningsstatus bekræfter, at kommandoen lykkedes. Vi kan nu tilføje følgende linje i bunden af PostgreSQL-konfigurationsfilen og genstarte instansen:
archive_mode = on[email protected]:~# systemctl restart [email protected]
Da vores data vil blive kopieret i et fjernlager uden for vores kontrol, er det vigtigt, at vi gemmer dem komprimeret og krypteret .
barman-cloud-wal-archivekommandoen understøtter to forskellige metoder til komprimering:[email protected]:~$ barman-cloud-wal-archive --help [...] -z, --gzip gzip-compress the WAL while uploading to the cloud -j, --bzip2 bzip2-compress the WAL while uploading to the cloud -e ENCRYPTION, --encryption ENCRYPTION Enable server-side encryption for the transfer. Allowed values: 'AES256', 'aws:kms' [...]
Krypteringsmuligheden vil blot informere S3-bøtten, hvilken metode der skal bruges til at opbevare dataene krypteret. Krypterede data kan ikke læses af andre AWS-brugere end ejeren af bøtten. Barman-skyen krypterer ikke noget objekt, før det sendes til S3, den beder bare bøtten om at gemme dem krypteret, hvis S3 er blevet korrekt konfigureret. Dog er enhver forbindelse til S3 sikkert etableret via
https.Lad os tilføje følgende linje i bunden af
postgresql.conffil:archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'Denne gang er blot en genindlæsning af konfigurationen nok til at anvende de nye ændringer:
[email protected]:~$ psql -c “SELECT pg_reload_conf()”
For at teste om den nye archive_command virker, bør PostgreSQL producere WAL-filer, der skal arkiveres, derfor er vi nødt til at lave noget trafik ved hjælp af
pgbenchværktøj:[email protected]:~$ createdb pg_bench_db [email protected]:~$ pgbench -i -s10 pg_bench_db [some irrelevant output here] [email protected]:~$ pgbench -c 10 -j 2 -T 30 pg_bench_db starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 10 query mode: simple number of clients: 10 number of threads: 2 duration: 30 s number of transactions actually processed: 84501 latency average = 3.552 ms tps = 2815.224687 (including connections establishing) tps = 2815.427535 (excluding connections establishing)
På dette tidspunkt skulle vi se WAL-filer arkiveret i S3-bøtten. Lad os tjekke det, opbygge målstien med servernavnet og WAL-destinationsmappen:
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/ PRE 0000000100000000/
Lad os tage et kig inde i 0000000100000000 biblioteket:
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/0000000100000000/ 2020-01-08 08:20:54 1624168 000000010000000000000001.bz2 2020-01-08 08:21:00 293422 000000010000000000000002.bz2 2020-01-08 08:21:06 301934 000000010000000000000003.bz2 2020-01-08 08:21:11 295648 000000010000000000000004.bz2 2020-01-08 08:21:16 293675 000000010000000000000005.bz2 2020-01-08 08:21:21 299348 000000010000000000000006.bz2 2020-01-08 08:21:27 551249 000000010000000000000007.bz2 2020-01-08 08:21:33 976523 000000010000000000000008.bz2 2020-01-08 08:21:37 4542104 000000010000000000000009.bz2 2020-01-08 08:21:46 5052693 00000001000000000000000A.bz2
Fantastisk!
WAL-filer bliver komprimeret, før de uploades til S3-bøtten og opbevares krypteret, hvilket sparer os plads (og penge) og øger sikkerhedsniveauet for vores data.
Konklusioner
barman-cloud-wal-archivekommandoen er, hvad brugerne har ventet på i lang tid.Hvis du er en af dem, der har brugt
pre_archive_retry_scriptat implementere et brugerdefineret script til at uploade WAL-filer til en S3-bøtte, så kan dette bruges som en bedre erstatning, fordi det er udviklet og vedligeholdt af Barman-udviklere, og det er testet og leveret af 2ndQuadrant Continuous Delivery-systemet.Hvis du ikke har tænkt over det endnu, åbner dette op for nye opbevaringspolitikker, som kan være længere for skylagring end de lokale Barman, hvilket øger objekternes alder i skyen, samtidig med at du sparer plads på det lokale lager ved at indstille korrekt. en længere opbevaringspolitik i S3 buckets' konfiguration.
Ellers kan den bruges, som vi gjorde i denne artikel, til at arkivere WAL-filer direkte fra PostgreSQL-serveren. Selvom dette fjerner et mellemtrin, er RPO stiger sammenlignet med streamingmetoden, fordi PostgreSQL først vil arkivere WAL-filen efter at have lukket den. Derfor kan vi miste nogle ændringer i tilfælde af problemer på PostgreSQL-noden. Når det er muligt, anbefaler vi at implementere denne metode sammen med streamingen til en Barman-server for at opnå RPO=0 (med synkron streaming).
Nu hvor vi har et kontinuerligt arkiveringssystem på plads, kan vi tage vores første skybackup ved hjælp af
barman-cloud-backupværktøj.Vi ses i anden del af artiklen.