Er moeten veel krachtige tools beschikbaar zijn als back-up- en hersteloptie voor PostgreSQL in het algemeen; Barman, PgBackRest, BART zijn om er in deze context een paar te noemen. Wat onze aandacht trok, was dat Barman een tool is die de productie-implementatie en markttrends snel inhaalt.
Of het nu een op docker gebaseerde implementatie is, back-up moet worden opgeslagen in een andere cloudopslag of zeer aanpasbare noodherstelarchitectuur nodig heeft - Barman is in al dergelijke gevallen een zeer sterke concurrent.
Deze blog onderzoekt Barman met weinig aannames over implementatie, maar dit mag in geen geval worden beschouwd als alleen mogelijke functies. Barman gaat veel verder dan wat we in deze blog kunnen vastleggen en moet verder worden onderzocht als 'back-up en herstel van PostgreSQL-instantie' wordt overwogen.
Aanname van DR Ready-implementatie
RPO=0 heeft over het algemeen een prijs - synchrone standby-serverimplementatie zou daar vaak aan voldoen, maar dan heeft het vrij vaak invloed op de TPS van de primaire server.
Net als PostgreSQL biedt Barman talloze implementatie-opties om aan uw behoeften te voldoen als het gaat om RPO versus prestaties. Denk aan eenvoud van implementatie, RPO=0 of bijna nul impact op de prestaties; Barman past in iedereen.
We hebben de volgende implementatie overwogen om een noodhersteloplossing voor onze back-up- en herstelarchitectuur op te zetten.
Afbeelding 1:PostgreSQL-implementatie met BarmanEr zijn twee sites (zoals in het algemeen voor rampherstelsites) - Site-X en Site-Y.
In Site-X is er:
- Eén server 'pgServer' die een PostgreSQL-serverinstantie pgServer host en één OS-gebruiker 'postgres'
- PostgreSQL-instantie ook om een superuser-rol 'bmuser' te hosten
- Eén server 'bServer' die de Barman-binaire bestanden host en een OS-gebruiker 'bmuser'
In Site-Y is er:
- Eén server 'geobServer' die de Barman-binaire bestanden host en een OS-gebruiker 'bmuser'
Er zijn meerdere soorten verbindingen bij deze configuratie betrokken.
- Tussen 'bServer' en 'pgServer':
- Management-plane-connectiviteit van Barman naar de PostgreSQL-instantie
- rsync-connectiviteit om daadwerkelijke basisback-up uit te voeren van Barman naar de PostgreSQL-instantie
- WAL-archivering met barman-wal-archive van de PostgreSQL-instantie naar Barman
- WAL-streaming met pg_receivexlog bij Barman
- Tussen 'bServer' en 'geobserver':
- Synchronisatie tussen Barman-servers om geo-replicatie te bieden
Connectiviteit eerst
De primaire connectiviteitsbehoeften tussen de servers zijn via ssh. Om het wachtwoordloze ssh-sleutels te maken, worden ssh-sleutels gebruikt. Laten we de ssh-sleutels maken en deze uitwisselen.
Op 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"Op 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"Op 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-instantieconfiguratie
Er zijn twee belangrijke dingen die we nodig hebben om een postgres-instantie opnieuw samen te stellen:de basisdirectory en de WAL / Transactions-logboeken die daarna worden gegenereerd. Barman-server houdt ze intelligent bij. Wat we nodig hebben, is ervoor te zorgen dat de juiste feeds worden gegenereerd zodat Barman deze artefacten kan verzamelen.
Voeg de volgende regels toe aan 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'Archiefopdracht zorgt ervoor dat wanneer WAL moet worden gearchiveerd door een postgres-instantie, het hulpprogramma barman-wal-archive het naar de Barman Server verzendt. Opgemerkt moet worden dat het barman-cli-pakket daarom beschikbaar moet worden gesteld op 'pgServer'. Er is nog een andere optie om rsync te gebruiken als we het hulpprogramma barman-wal-archive niet willen gebruiken.
Voeg het volgende toe aan pg_hba.conf:
host all all 172.25.130.186/32 md5
host replication all 172.25.130.186/32 md5Het staat in feite een replicatie en een normale verbinding toe van 'bmserver' naar deze postgres-instantie.
Start nu gewoon de instantie opnieuw en maak een supergebruikersrol aan met de naam bmuser:
[email protected]$ pg_ctl restart
[email protected]$ createuser -s -P bmuser Indien nodig kunnen we vermijden om bmuser ook als supergebruiker te gebruiken; waarvoor privileges nodig zijn die aan deze gebruiker zijn toegewezen. Voor het bovenstaande voorbeeld hebben we bmuser ook als wachtwoord gebruikt. Maar dat is zo'n beetje alles, voor zover een PostgreSQL-instantieconfiguratie vereist is.
Barman-configuratie
Barman heeft drie basiscomponenten in zijn configuratie:
- Algemene configuratie
- Configuratie op serverniveau
- Gebruiker die de barman gaat leiden
In ons geval, aangezien Barman is geïnstalleerd met rpm, hebben we onze algemene configuratiebestanden opgeslagen op:
/etc/barman.confWe wilden de configuratie op serverniveau opslaan in de homedirectory van bmuser, vandaar dat ons globale configuratiebestand de volgende inhoud had:
[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 = INFOPrimaire Barman-serverconfiguratie
In de bovenstaande implementatie hebben we besloten om de primaire Barman-server in hetzelfde datacenter / dezelfde site te houden waar de PostgreSQL-instantie wordt bewaard. Het voordeel van hetzelfde is dat er minder vertraging is en sneller herstel indien nodig. Onnodig te zeggen dat er ook minder computer- en/of netwerkbandbreedte nodig is op de PostgreSQL-server.
Om Barman de PostgreSQL-instantie op de pgServer te laten beheren, moeten we een configuratiebestand toevoegen (we hebben pgserver.conf genoemd) met de volgende inhoud:
[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 = autoEn een .pgpass-bestand met de inloggegevens voor bmuser in de PostgreSQL-instantie:
echo 'pgserver:5432:*:bmuser:bmuser' > ~/.pgpass Om de belangrijke configuratie-items wat beter te begrijpen:
- ssh_command :Wordt gebruikt om verbinding tot stand te brengen waarover rsync zal worden uitgevoerd
- conninfo :Verbindingsreeks om Barman verbinding te laten maken met de postgres-server
- reuse_backup :om incrementele back-ups toe te staan met minder opslagruimte
- backup_methode :methode om een back-up te maken van de basismap
- path_prefix :locatie waar pg_receivexlog binaire bestanden worden opgeslagen
- streaming_conninfo :verbindingsreeks die wordt gebruikt om WAL te streamen
- create_slot :om ervoor te zorgen dat slots zijn gemaakt door de postgres-instantie
Passieve Barman-serverconfiguratie
De configuratie van een geo-replicatiesite is vrij eenvoudig. Het enige dat nodig is, is een ssh-verbindingsinformatie waarover deze passieve node-site de replicatie zal doen.
Wat interessant is, is dat zo'n passief knooppunt in mix-modus kan werken; met andere woorden - ze kunnen fungeren als actieve Barman-servers om back-ups te maken voor PostgreSQL-sites en tegelijkertijd fungeren als een replicatie/cascade-site voor andere Barman-servers.
Aangezien in ons geval deze instantie van Barman (op Site-Y) slechts een passief knooppunt hoeft te zijn, hoeven we alleen het bestand /home/bmuser/barman.d/pgserver.conf aan te maken met de volgende configuratie:
[pgserver]
description = "Geo-replication or sync for pgserver"
primary_ssh_command = ssh [email protected]In de veronderstelling dat de sleutels zijn uitgewisseld en de globale configuratie op dit knooppunt is gedaan zoals eerder vermeld - we zijn zo goed als klaar met de configuratie.
En hier is onze eerste back-up en herstel
Controleer op de bserver of het achtergrondproces om WAL te ontvangen is geactiveerd; en controleer vervolgens de configuratie van de server:
[email protected]$ barman cron
[email protected]$ barman check pgserverDe controle zou in orde moeten zijn voor alle substappen. Als dat niet het geval is, raadpleeg dan /home/bmuser/barman.log.
Geef een back-upopdracht op Barman om er zeker van te zijn dat er een basis DATA is waarop WAL kan worden toegepast:
[email protected]$ barman backup pgserverZorg ervoor dat de replicatie op de 'geobmserver' wordt gedaan door de volgende opdrachten uit te voeren:
[email protected]$ barman cron
[email protected]$ barman list-backup pgserverDe cron moet in het crontab-bestand worden ingevoegd (indien niet aanwezig). Voor de eenvoud heb ik het hier niet getoond. Het laatste commando laat zien dat de back-upmap ook op de geobmserver is aangemaakt.
Laten we nu op de Postgres-instantie enkele dummy-gegevens maken:
[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 ));"De replicatie van de WAL van de PostgreSQL-instantie kan worden bekeken met het onderstaande commando:
[email protected]$ psql -U postgres -c "SELECT * from pg_stat_replication ;”Om een instantie opnieuw te maken op Site-Y, moet u er eerst voor zorgen dat WAL-records worden omgeschakeld. of dit voorbeeld om een schoon herstel te maken:
[email protected]$ barman switch-xlog --force --archive pgserverLaten we op de Site-X een standalone PostgreSQL-instantie ter sprake brengen om te controleren of de back-up verstandig is:
[email protected]$ barman cron
barman recover --get-wal pgserver latest /tmp/dataBewerk nu de postgresql.conf en de postgresql.auto.conf bestanden naar behoefte. Hieronder wordt uitgelegd welke wijzigingen voor dit voorbeeld zijn aangebracht:
- postgresql.conf :listen_addresses heeft gereageerd om standaard localhost te worden
- postgresql.auto.conf :sudo bmuser verwijderd uit restore_command
Breng deze GEGEVENS op in /tmp/data en controleer het bestaan van uw records.
Conclusie
Dit was slechts het topje van een ijsberg. Barman gaat veel dieper dan dit vanwege de functionaliteit die het biedt - b.v. fungeren als een gesynchroniseerde stand-by, hook-scripts enzovoort. Vanzelfsprekend moet de volledige documentatie worden onderzocht om deze te configureren volgens de behoeften van uw productieomgeving.