Det måste finnas många kraftfulla verktyg tillgängliga som backup- och återställningsalternativ för PostgreSQL i allmänhet; Barman, PgBackRest, BART är för att nämna några i detta sammanhang. Det som fångade vår uppmärksamhet var att Barman är ett verktyg som snabbt kommer ikapp med produktionsinstallation och marknadstrender.
Oavsett om det är en dockningsbaserad implementering, behov av att lagra säkerhetskopiering i en annan molnlagring eller mycket anpassningsbar arkitektur för katastrofåterställning - Barman är en mycket stark utmanare i alla sådana fall.
Den här bloggen utforskar Barman med få antaganden om distribution, men i inget fall bör detta endast betraktas som en möjlig funktionsuppsättning. Barman är långt bortom vad vi kan fånga i den här bloggen och måste utforskas vidare om "säkerhetskopiering och återställning av PostgreSQL-instans" övervägs.
DR Ready Deployment Assumption
RPO=0 har i allmänhet en kostnad - synkron standby-serverdistribution skulle ofta uppfylla det, men sedan påverkar det TPS för den primära servern ganska ofta.
Precis som PostgreSQL ger Barman många distributionsalternativ för att möta dina behov när det kommer till RPO kontra prestanda. Tänk på enkel installation, RPO=0 eller nästan noll prestandapåverkan; Barman passar i alla.
Vi övervägde följande distribution för att etablera en katastrofåterställningslösning för vår säkerhetskopierings- och återställningsarkitektur.
Figur 1:PostgreSQL-distribution med BarmanDet finns två platser (som i allmänhet för webbplatser för katastrofåterställning) - Site-X och Site-Y.
I Site-X finns:
- En server 'pgServer' som är värd för en PostgreSQL-serverinstans pgServer och en OS-användare 'postgres'
- PostgreSQL-instans även att vara värd för en superanvändarroll 'bmuser'
- En server 'bServer' som är värd för Barman-binärfilerna och en OS-användare 'bmuser'
I Site-Y finns:
- En server 'geobServer' som är värd för Barman-binärfilerna och en OS-användare 'bmuser'
Det finns flera typer av anslutningar involverade i den här installationen.
- Mellan ‘bServer’ och ‘pgServer’:
- Management-plane-anslutning från Barman till PostgreSQL-instansen
- rsync-anslutning för att göra faktisk bassäkerhetskopiering från Barman till PostgreSQL-instansen
- WAL-arkivering med barman-wal-archive från PostgreSQL-instansen till Barman
- WAL-strömning med pg_receivexlog på Barman
- Mellan ‘bServer’ och ‘geobserver’:
- Synkronisering mellan Barman-servrar för att tillhandahålla geo-replikering
Anslutning först
Det primära anslutningsbehovet mellan servrarna är via ssh. För att göra det lösenordslösa används ssh-nycklar. Låt oss upprätta ssh-nycklarna och byta ut 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-instanskonfiguration
Det finns två huvudsakliga saker som vi behöver för att återskapa en postgres-instans - Baskatalogen och WAL/Transactions-loggarna som genereras därefter. Barman-servern håller reda på dem intelligent. Vad vi behöver är att se till att rätt flöden genereras så att Barman kan samla in dessa artefakter.
Lägg till följande rader till 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'Arkivkommandot säkerställer att när WAL ska arkiveras av postgres-instans, skickar barman-wal-archive-verktyget det till Barman-servern. Det bör noteras att barman-cli-paketet därför bör göras tillgängligt på "pgServer". Det finns ett annat alternativ att använda rsync om vi inte vill använda verktyget barman-wal-archive.
Lägg till följande till pg_hba.conf:
host all all 172.25.130.186/32 md5
host replication all 172.25.130.186/32 md5Det tillåter i princip en replikering och en normal anslutning från 'bmserver' till denna postgres-instans.
Starta bara om instansen och skapa en superanvändarroll som heter bmuser:
[email protected]$ pg_ctl restart
[email protected]$ createuser -s -P bmuser Om det behövs kan vi undvika att använda bmuser som superanvändare också; som skulle behöva privilegier tilldelade den här användaren. För exemplet ovan använde vi bmuser som lösenord också. Men det är i stort sett allt, så långt som en PostgreSQL-instanskonfiguration krävs.
Barman-konfiguration
Barman har tre grundläggande komponenter i sin konfiguration:
- Global konfiguration
- Konfiguration på servernivå
- Användare som kommer att köra barman
I vårt fall, eftersom Barman installeras med rpm, har vi haft våra globala konfigurationsfiler lagrade på:
/etc/barman.confVi ville lagra servernivåkonfigurationen i bmusers hemkatalog, därför hade vår globala konfigurationsfil följande innehåll:
[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 = INFOKonfiguration av primär Barman-server
I implementeringen ovan bestämde vi oss för att behålla den primära Barman-servern i samma datacenter/webbplats där PostgreSQL-instansen förvaras. Fördelen med detsamma är att det blir mindre fördröjning och snabbare återhämtning om det skulle behövas. Det behöver inte sägas att det krävs mindre dator- och/eller nätverksbandbredd på PostgreSQL-servern också.
För att låta Barman hantera PostgreSQL-instansen på pgServer, måste vi lägga till en konfigurationsfil (vi heter pgserver.conf) med följande innehåll:
[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 = autoOch en .pgpass-fil som innehåller autentiseringsuppgifterna för bmuser i PostgreSQL-instansen:
echo 'pgserver:5432:*:bmuser:bmuser' > ~/.pgpass För att förstå de viktiga konfigurationsobjekten lite mer:
- ssh_command :Används för att upprätta en anslutning över vilken rsync kommer att göras
- konninfo :Anslutningssträng för att låta Barman upprätta anslutning till postgres-servern
- reuse_backup :För att tillåta inkrementell säkerhetskopiering med mindre lagringsutrymme
- backup_metod :metod för att ta backup av baskatalogen
- sökvägsprefix :plats där pg_receivexlog binärer lagras
- streaming_conninfo :Anslutningssträng som används för att streama WAL
- create_slot :För att säkerställa att platser har skapats av postgres-instansen
Passive Barman Server Configuration
Konfigurationen av en geo-replikeringsplats är ganska enkel. Allt den behöver är en ssh-anslutningsinformation över vilken den här passiva nodplatsen kommer att replikera.
Det som är intressant är att en sådan passiv nod kan fungera i mix-läge; med andra ord - de kan fungera som aktiva Barman-servrar för att göra säkerhetskopior för PostgreSQL-webbplatser och parallellt fungera som en replikerings-/kaskadwebbplats för andra Barman-servrar.
Eftersom den här instansen av Barman (på Site-Y) i vårt fall bara behöver vara en passiv nod, behöver vi bara skapa filen /home/bmuser/barman.d/pgserver.conf med följande konfiguration:
[pgserver]
description = "Geo-replication or sync for pgserver"
primary_ssh_command = ssh [email protected]Med ett antagande om att nycklarna har bytts ut och den globala konfigurationen på denna nod görs som tidigare nämnt - vi är i stort sett klara med konfigurationen.
Och här är vår första säkerhetskopiering och återställning
Se till att bakgrundsprocessen för att ta emot WAL på bservern har utlösts; och kontrollera sedan serverns konfiguration:
[email protected]$ barman cron
[email protected]$ barman check pgserverKontrollen bör vara OK för alla delsteg. Om inte, se /home/bmuser/barman.log.
Utfärda backupkommando på Barman för att säkerställa att det finns en basdata som WAL kan tillämpas på:
[email protected]$ barman backup pgserverPå 'geobmserver' se till att replikeringen görs genom att utföra följande kommandon:
[email protected]$ barman cron
[email protected]$ barman list-backup pgserverCron ska infogas i crontab-filen (om den inte finns). För enkelhetens skull har jag inte visat det här. Det sista kommandot kommer att visa att backupmappen har skapats på geobmservern också.
Låt oss nu i Postgres-instansen skapa lite dummydata:
[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 av WAL från PostgreSQL-instansen kan ses med kommandot nedan:
[email protected]$ psql -U postgres -c "SELECT * from pg_stat_replication ;”För att återskapa en instans på Site-Y, se först till att WAL-poster byts över. eller det här exemplet, för att skapa en ren återställning:
[email protected]$ barman switch-xlog --force --archive pgserverPå Site-X, låt oss ta upp en fristående PostgreSQL-instans för att kontrollera om säkerhetskopieringen är korrekt:
[email protected]$ barman cron
barman recover --get-wal pgserver latest /tmp/dataRedigera nu postgresql.conf och postgresql.auto.conf-filerna enligt behoven. Följande förklara ändringarna som gjorts för detta exempel:
- postgresql.conf :listen_addresses kommenterade för att vara standard till localhost
- postgresql.auto.conf :tog bort sudo bmuser från restore_command
Ta fram denna DATA i /tmp/data och kontrollera existensen av dina poster.
Slutsats
Detta var bara toppen av ett isberg. Barman är mycket djupare än så här på grund av funktionaliteten den tillhandahåller - t.ex. fungerar som ett synkroniserat standby-läge, haka skript och så vidare. Det behöver inte sägas att dokumentationen i sin helhet bör utforskas för att konfigurera den enligt behoven i din produktionsmiljö.