Brug af Barman til PostgreSQL Disaster Recovery

Der skal være mange kraftfulde værktøjer tilgængelige som backup- og gendannelsesmulighed for PostgreSQL generelt; Barman, PgBackRest, BART er for at nævne nogle få i denne sammenhæng. Det, der fangede vores opmærksomhed, var, at Barman er et værktøj, der hurtigt indhenter produktionsimplementering og markedstendenser.

Uanset om det er en docker-baseret udrulning, behov for at gemme backup i et andet cloudlager eller behov for meget tilpasselig katastrofegendannelsesarkitektur - Barman er en meget stærk konkurrent i alle sådanne tilfælde.

Denne blog udforsker Barman med få antagelser om implementering, men i intet tilfælde bør dette kun betragtes som muligt funktionssæt. Barman er langt ud over, hvad vi kan fange i denne blog og skal udforskes yderligere, hvis 'backup og gendannelse af PostgreSQL-instans' overvejes.

DR Ready Deployment Assumption

RPO=0 har generelt en pris - synkron standby-serverinstallation ville ofte opfylde det, men så påvirker det TPS'en for den primære server ret ofte.

Ligesom PostgreSQL giver Barman adskillige implementeringsmuligheder for at opfylde dine behov, når det kommer til RPO vs. ydeevne. Tænk på enkel implementering, RPO=0 eller næsten ingen præstationspåvirkning; Barmand passer ind i alle.

Vi overvejede følgende implementering for at etablere en katastrofegendannelsesløsning til vores backup- og gendannelsesarkitektur.

Figur 1:PostgreSQL-implementering med Barman

Der er to websteder (som generelt for websteder til gendannelse af katastrofer) - Site-X og Site-Y.

I Site-X er der:

Én server 'pgServer', der hoster en PostgreSQL-serverinstans pgServer, og en OS-bruger 'postgres'
- PostgreSQL-instans skal også være vært for en superbrugerrolle 'bmuser'
Én server 'bServer', der hoster Barman-binære filer og en OS-bruger 'bmuser'

I Site-Y er der:

Én server 'geobServer', der hoster Barman-binære filer og en OS-bruger 'bmuser'

Der er flere typer forbindelse involveret i denne opsætning.

Mellem 'bServer' og 'pgServer':
- Management-plane-forbindelse fra Barman til PostgreSQL-instansen
- rsync-forbindelse til at lave egentlig basissikkerhedskopiering fra Barman til PostgreSQL-forekomsten
- WAL-arkivering ved hjælp af barman-wal-archive fra PostgreSQL-forekomsten til Barman
- WAL-streaming ved hjælp af pg_receivexlog hos Barman
Mellem 'bServer' og 'geobserver':
- Synkronisering mellem Barman-servere for at give geo-replikering

Forbindelse først

Det primære behov for forbindelse mellem serverne er via ssh. For at gøre det password-mindre bruges ssh-nøgler. Lad os etablere ssh-nøglerne og udveksle dem.

På pgServer:

[email protected]$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

[email protected]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

[email protected]$ ssh [email protected] "chmod 600 ~/.ssh/authorized_keys"

På bServer:

[email protected]$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

[email protected]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

[email protected]$ ssh [email protected] "chmod 600 ~/.ssh/authorized_keys"

På geobServer:

[email protected]$ ssh-keygen -q -t rsa -N '' -f ~/.ssh/id_rsa <<<y 2>&1 >/dev/null

[email protected]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

[email protected]$ ssh [email protected] "chmod 600 ~/.ssh/authorized_keys"

PostgreSQL-forekomstkonfiguration

Der er to hovedting, som vi skal bruge for at rekonstituere en postgres-instans - Basismappen og WAL/Transactions-logfilerne, der genereres derefter. Barman-serveren holder intelligent styr på dem. Det, vi har brug for, er at sikre, at der genereres ordentlige feeds, så Barman kan indsamle disse artefakter.

Tilføj følgende linjer til postgresql.conf:

listen_addresses = '172.25.130.180'     #as per above deployment assumption

wal_level = replica                     #or higher 

archive_mode = on

archive_command = 'barman-wal-archive -U bmuser bserver pgserver %p'

Arkivkommandoen sikrer, at når WAL skal arkiveres af postgres-instansen, sender barman-wal-archive-værktøjet det til Barman-serveren. Det skal bemærkes, at barman-cli-pakken derfor bør gøres tilgængelig på 'pgServer'. Der er en anden mulighed for at bruge rsync, hvis vi ikke ønsker at bruge barman-wal-archive-værktøjet.

Tilføj følgende til pg_hba.conf:

host     all                    all     172.25.130.186/32     md5

host     replication            all     172.25.130.186/32     md5

Det tillader grundlæggende en replikering og en normal forbindelse fra 'bmserver' til denne postgres-instans.

Nu skal du bare genstarte forekomsten og oprette en superbrugerrolle kaldet bmuser:

[email protected]$ pg_ctl restart

[email protected]$ createuser -s -P bmuser

Hvis det er nødvendigt, kan vi også undgå at bruge bmuser som superbruger; som ville kræve privilegier tildelt denne bruger. Til ovenstående eksempel brugte vi også bmuser som adgangskode. Men det er stort set alt, hvad angår en PostgreSQL-instanskonfiguration er påkrævet.

Barman-konfiguration

Barman har tre grundlæggende komponenter på sin konfiguration:

Global konfiguration
Konfiguration på serverniveau
Bruger, der skal køre barmanden

I vores tilfælde, da Barman er installeret ved hjælp af rpm, har vi haft vores globale konfigurationsfiler gemt på:

/etc/barman.conf

Vi ønskede at gemme konfigurationen på serverniveau i bmuser-hjemmebiblioteket, derfor havde vores globale konfigurationsfil følgende indhold:

[barman]

barman_user = bmuser

configuration_files_directory = /home/bmuser/barman.d

barman_home = /home/bmuser

barman_lock_directory = /home/bmuser/run

log_file = /home/bmuser/barman.log

log_level = INFO

Primary Barman Server Configuration

I installationen ovenfor besluttede vi at beholde den primære Barman-server i det samme datacenter/sted, hvor PostgreSQL-instansen opbevares. Fordelen ved det samme er, at der er mindre forsinkelse og hurtigere genopretning i tilfælde af behov. Det er overflødigt at sige, at der også kræves mindre behov for databehandling og/eller netværksbåndbredde på PostgreSQL-serveren.

For at lade Barman administrere PostgreSQL-forekomsten på pgServeren, skal vi tilføje en konfigurationsfil (vi kaldte pgserver.conf) med følgende indhold:

[pgserver]

description =  "Example pgserver configuration"

ssh_command = ssh [email protected]

conninfo = host=pgserver user=bmuser dbname=postgres

backup_method = rsync

reuse_backup = link

backup_options = concurrent_backup

parallel_jobs = 2

archiver = on

archiver_batch_size = 50

path_prefix = "/usr/pgsql-12/bin"



streaming_conninfo = host=pgserver user=bmuser dbname=postgres

streaming_archiver=on

create_slot = auto

Og en .pgpass-fil, der indeholder legitimationsoplysningerne for bmuser i PostgreSQL-forekomsten:

echo 'pgserver:5432:*:bmuser:bmuser' > ~/.pgpass

For at forstå de vigtige konfigurationselementer lidt mere:

ssh_command :Bruges til at etablere forbindelse, som rsync skal udføres over
conninfo :Forbindelsesstreng for at lade Barman etablere forbindelse med postgres server
reuse_backup :For at tillade trinvis sikkerhedskopiering med mindre lagerplads
backup_method :metode til at tage backup af basisbiblioteket
sti_præfiks :placering, hvor pg_receivexlog binære filer er gemt
streaming_conninfo :Forbindelsesstreng, der bruges til at streame WAL
create_slot :For at sikre, at pladser er oprettet af postgres-instansen

Passive Barman-serverkonfiguration

Konfigurationen af et geo-replikeringssted er ret simpel. Det eneste, den behøver, er en ssh-forbindelsesinformation, som dette passive nodested vil udføre replikeringen over.

Det interessante er, at sådan en passiv node kan fungere i mix-mode; med andre ord - de kan fungere som aktive Barman-servere til at lave sikkerhedskopier til PostgreSQL-websteder og sideløbende fungere som et replikerings-/kaskadested for andre Barman-servere.

Da denne forekomst af Barman (på Site-Y) i vores tilfælde kun skal være en passiv node, er det eneste, vi behøver at oprette filen /home/bmuser/barman.d/pgserver.conf med følgende konfiguration:

[pgserver]

description =  "Geo-replication or sync for pgserver"

primary_ssh_command = ssh [email protected]

Med en antagelse om, at nøglerne er blevet udvekslet, og den globale konfiguration på denne node er udført som tidligere nævnt - vi er stort set færdige med konfigurationen.

Og her er vores første sikkerhedskopiering og gendannelse

På bserveren skal du sikre dig, at baggrundsprocessen for at modtage WAL er blevet udløst; og kontroller derefter serverens konfiguration:

[email protected]$ barman cron

[email protected]$ barman check pgserver

Tjekket skal være OK for alle undertrin. Hvis ikke, se /home/bmuser/barman.log.

Udfør backup-kommando på Barman for at sikre, at der er en base DATA, som WAL kan anvendes på:

[email protected]$ barman backup pgserver

På 'geobmserver' skal du sikre dig, at replikeringen udføres ved at udføre følgende kommandoer:

[email protected]$ barman cron 

[email protected]$ barman list-backup pgserver

Cronet skal indsættes i crontab-filen (hvis den ikke findes). For nemheds skyld har jeg ikke vist det her. Den sidste kommando vil vise, at backup-mappen også er blevet oprettet på geobmserveren.

Nu i Postgres-forekomsten, lad os oprette nogle dummy-data:

[email protected]$ psql -U postgres -c "CREATE TABLE dummy_data( i INTEGER);"

[email protected]$ psql -U postgres -c "insert into dummy_data values ( generate_series (1, 1000000 ));"

Replikeringen af WAL'en fra PostgreSQL-instansen kan ses ved hjælp af nedenstående kommando:

[email protected]$ psql -U postgres -c "SELECT * from pg_stat_replication ;”

For at genskabe en forekomst på Site-Y, skal du først sikre dig, at WAL-poster skifter. eller dette eksempel for at skabe en ren gendannelse:

[email protected]$ barman switch-xlog --force --archive pgserver

På Site-X, lad os hente en selvstændig PostgreSQL-instans for at kontrollere, om sikkerhedskopieringen er fornuftig:

[email protected]$ barman cron 

barman recover --get-wal pgserver latest /tmp/data

Rediger nu postgresql.conf og postgresql.auto.conf filerne efter behov. Forklar ændringerne i dette eksempel nedenfor:

postgresql.conf :listen_addresses kommenterede for at blive standard til localhost
postgresql.auto.conf :fjernede sudo bmuser fra restore_command

Få disse DATA frem i /tmp/data og kontroller eksistensen af dine poster.

Konklusion

Dette var kun toppen af et isbjerg. Barman er langt dybere end dette på grund af den funktionalitet, den giver - f.eks. fungerer som en synkroniseret standby, hook scripts og så videre. Det er overflødigt at sige, at dokumentationen i sin helhed bør undersøges for at konfigurere den efter behovene i dit produktionsmiljø.