Ingress
Hur många nuvarande Barman-användare har tänkt på att spara säkerhetskopior på en avlägsen destination i molnet? Hur många har tänkt på att ta den säkerhetskopian direkt från själva PostgreSQL-servern?
Tja, sedan Barman 2.10 detta är nu möjligt!
Hur?
Låt oss upptäcka det tillsammans i följande artiklar.
Krav
Följande två artiklar är tänkta att vara en praktisk introduktion till det nya barman-cloud-wal-archive och barman-cloud-backup verktyg som läggs till i barman-cli paketet.
Den första delen kommer att täcka barman-cloud-wal-archive kommandot medan det andra täcker barman-cloud-backup kommando.
Läsare behöver en grundläggande kunskap om PostgreSQL WAL-arkivering och säkerhetskopieringsmetoder, och Barman. Det rekommenderas också att du är medveten om molnteknik för lagringslösningar som Amazon S3.
WAL-arkiv
Barman har agerat som ett fjärr-WAL-arkiv i många år, och Barman CLI-paketet har utformats för att utöka arkiveringens tillförlitlighet och robusthet på PostgreSQL-sidan. Faktum är att barman-cli tillhandahåller skript som barman-wal-restore tillåter en standby-nod att smart och säkert återställa WAL-filer från ett Barman-arkiv genom restore_command parametern i postgresql.auto.conf fil (eller recovery.conf fil tills PostgreSQL 12), och barman-wal-archive för att arkivera WAL-filer från en masternod till Barman genom archive_command parameter konfigurerad i postgresql.conf fil.
Cloud WAL-arkiv
Tack vare användarnas feedback har Barman-utvecklarna introducerat två nya verktyg i version 2.10 :
barman-cloud-wal-archivebarman-cloud-backup
Version 2.11 kommer att innehålla ytterligare två verktyg för återställning, kallade barman-cloud-wal-restore och barman-cloud-restore .
Det här inlägget är helt tillägnat barman-cloud-wal-archive , som kan lagra WAL-filer i molnet, vilket möjliggör flerskiktsarkivering med Barman och utökar säkerhetskopieringspolicyn.
Faktiskt, barman-cloud-wal-archive kan användas som ett hook-script som konfigurerar pre_archive_retry_script parameter i Barman, för att kopiera WAL-filer i den konfigurerade molnlagringen, vilket ökar redundansen i arkivet och gör det möjligt att välja en längre lagringspolicy än Barman.
Det är inte allt!
barman-cloud-wal-archive kan ersätta barman-wal-archive kommandot i archive_command parameter, för att direkt arkivera WAL-filer i molnet, istället för att kopiera dem till Barman-servern. På detta sätt kan även ett PostgreSQL-kluster som inte har en separat dedikerad backupserver förlita sig på fjärrlagringstjänst för att arkivera WAL-filer.
Hur fungerar det?
Följande instruktioner är bara för att installera och konfigurera barman-cloud-wal-archive som archive_command i PostgreSQL.
Bestämma först var WAL-filer ska arkiveras. I den här artikeln kommer vi att använda Amazon S3, som i skrivande stund är den enda teknik som stöds. Även om andra tekniker som stöder S3-liknande API (Google Cloud, DigitalOcean, Microsoft Azure, etc.) kan fungera med boto3-biblioteket, har de inte testats ännu.
Krav
- barman-cli 2.10 (eller högre)
- Amazon AWS-konto
- awscli
- S3 hink
- En PostgreSQL-instans
I den här artikeln kommer vi att testa Barman CLI i en virtuell maskin med Debian Buster och PostgreSQL 12 som redan är igång.
Installation
-
- Installera 2ndQuadrant Public repository
- Installera barman-cli-paketet
[email protected]:~# apt update [email protected]:~# apt install barman-cli
- Installera awscli
[email protected]:~# apt install awscli
Konfiguration och inställningar
Låt oss läsa 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å för att använda det korrekt behöver vi bara konfigurera AWS-uppgifter med
awscliverktyg sompostgresanvändare, kopiera åtkomstnyckeln och den hemliga nyckeln som tidigare skapats i IAM-sektionen i AWS-konsolen:[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
Se till att ha en tillgänglig S3-skopa på AWS. Jag valde att kalla det
barman-s3-testför att göra det tydligt.
Vi bör nu kunna testabarman-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
Exit-statusen bekräftar att kommandot lyckades. Vi kan nu lägga till följande rad längst ner i PostgreSQL-konfigurationsfilen och starta om instansen:
archive_mode = on[email protected]:~# systemctl restart [email protected]
Eftersom vår data kommer att kopieras till en fjärrlagring, utanför vår kontroll, är det viktigt att vi lagrar dem komprimerade och krypterad .
barman-cloud-wal-archivekommandot stöder två olika metoder för 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' [...]
Krypteringsalternativet kommer bara att informera S3-hinken vilken metod som ska användas för att lagra data krypterad. Krypterad data kan inte läsas av någon annan AWS-användare än ägaren av hinken. Barman-molnet krypterar inte något objekt innan det skickas till S3, det ber bara hinken att lagra dem krypterade om S3 har konfigurerats korrekt. Alla anslutningar till S3 upprättas dock säkert via
https.Låt oss lägga till följande rad längst ner i
postgresql.conffil:archive_command = 'barman-cloud-wal-archive -P barman-cloud -e AES256 -j s3://barman-s3-test/ pg12 %p'Den här gången räcker det med en omladdning av konfigurationen för att tillämpa de nya ändringarna:
[email protected]:~$ psql -c “SELECT pg_reload_conf()”
För att testa om det nya archive_command fungerar bör PostgreSQL producera WAL-filer som ska arkiveras, därför måste vi göra lite trafik med hjälp av
pgbenchverktyg:[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)
Vid det här laget bör vi se WAL-filer arkiverade i S3-hinken. Låt oss kontrollera det, bygga målsökvägen med servernamnet och WAL-destinationskatalogen:
[email protected]:~$ aws s3 --profile barman-cloud ls s3://barman-s3-test/pg12/wals/ PRE 0000000100000000/
Låt oss ta en titt i katalogen 0000000100000000:
[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
Bra!
WAL-filer komprimeras innan de laddas upp till S3-bucket och lagras krypterade, vilket sparar oss utrymme (och pengar) och ökar säkerhetsnivån för våra data.
Slutsatser
barman-cloud-wal-archivekommandot är vad användarna har väntat på länge.Om du är en av dem som har använt
pre_archive_retry_scriptför att implementera ett anpassat skript för att ladda upp WAL-filer till en S3-bucket, då kan detta användas som en bättre ersättning eftersom det är utvecklat och underhållet av Barman-utvecklare, och det testas och levereras av 2ndQuadrant Continuous Delivery-systemet.Om du inte har tänkt på det ännu, öppnar detta upp för nya lagringspolicyer som kan vara längre för molnlagring än de lokala Barman, vilket ökar objektens ålder i molnet, samtidigt som du sparar utrymme på den lokala lagringen, genom att ställa in korrekt. en längre lagringspolicy i S3-segmentens konfiguration.
Annars kan den användas som vi gjorde i den här artikeln, för att arkivera WAL-filer direkt från PostgreSQL-servern. Även om detta tar bort ett mellansteg, är RPO ökar jämfört med streamingmetoden, eftersom PostgreSQL kommer att arkivera WAL-filen först efter att ha stängt den. Därför kan vi förlora några ändringar vid problem på PostgreSQL-noden. När det är möjligt rekommenderar vi att du implementerar den här metoden tillsammans med strömning till en Barman-server för att uppnå RPO=0 (med synkron streaming).
Nu när vi har ett kontinuerligt arkiveringssystem på plats kan vi ta vår första molnsäkerhetskopia med
barman-cloud-backupverktyg.Vi ses i den andra delen av artikeln.