De huidige staat van open source back-upbeheer voor PostgreSQL

Er zijn veel manieren om het maken van back-ups van een PostgreSQL-cluster aan te pakken. Er zijn verschillende artikelen en blogs die de verschillende technologieën presenteren waarmee we onze kostbare gegevens in PostgreSQL kunnen opslaan. Er zijn logische back-upoplossingen, fysieke back-up op OS-niveau, op bestandssysteemniveau, enzovoort. Hier in deze blog gaan we niet het theoretische gedeelte behandelen dat voldoende wordt behandeld door verschillende blogs en artikelen, evenals de officiële documentatie.

Deze blog richt zich op de staat van de verschillende beschikbare tools en oplossingen en een poging om een ​​grondige vergelijking te presenteren op basis van ervaringen uit het echte leven. Dit artikel probeert op geen enkele manier een specifiek product te promoten, ik hou echt van alle tools, oplossingen en technologieën die in deze blog worden beschreven. Het doel hier is om hun sterke en zwakke punten te noteren en de eindgebruiker te begeleiden welke tool het beste past bij zijn/haar omgeving, infrastructuur en specifieke eisen. Hier is een mooi artikel dat back-uptools voor PostgreSQL op verschillende niveaus beschrijft.

Ik zal niet beschrijven hoe de verschillende tools in deze blog moeten worden gebruikt, aangezien deze informatie is gedocumenteerd in de bovenstaande blog en ook in de officiële documenten en andere bronnen op het net. Maar ik zal de voor- en nadelen beschrijven zoals ik ze in de praktijk heb ervaren. In deze blog hebben we het uitsluitend over klassieke op PITR gebaseerde fysieke PostgreSQL-back-ups, afhankelijk van:

• pg_basebackup of pg_start_backup()/pg_stop_backup
• fysieke kopie
• archivering van WAL's of streamingreplicatie

Er zijn verschillende mooie producten en oplossingen, sommige zijn open source en gratis te gebruiken, terwijl andere commercieel zijn. Voor zover ik weet zijn dat:

• pgbarman door 2ndquadrant (gratis)
• pgrugleuning (gratis)
• pg_probackup door Postgres Professional (gratis)
• BART door EDB (commercieel)

Ik heb niet de kans gehad om BART uit te proberen, omdat het draait op smaken van Linux die ik niet gebruik. In deze blog zal ik mijn eigen gedachten en indrukken opnemen tijdens interactie met de respectievelijke auteurs/gemeenschap/beheerders van elke oplossing, aangezien dit een zeer belangrijk aspect is dat in het begin meestal wordt onderschat. Een beetje terminologie om de verschillende termen in elk van de tools beter te begrijpen:

pgbarman

Pgbarman of gewoon barman is de oudste van die tools. De nieuwste release is 2.6 (uitgebracht terwijl ik aan deze blog werkte! wat geweldig nieuws is).

Pgbarman ondersteunt basisback-up via twee methoden:

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

en WAL-overdracht via:

• WAL-archivering
  • via rsync
  • via barman-wal-archive / put-wal
• WAL via streamingreplicatie met replicatieslot
  • Asynchroon
  • Synchroon

Dit geeft ons 8 kant-en-klare combinaties waarmee we barman kunnen gebruiken. Elk heeft zijn voor- en nadelen.

Basisback-up via pg_basebackup (backup_method =postgres)

Voordelen:

• de nieuwste/moderne manier
• vertrouwt op bewezen kern PostgreSQL-technologie
• aanbevolen door de officiële documenten

Nadelen:

• geen incrementele back-up
• geen parallelle back-up
• geen netwerkcompressie
• geen gegevensontdubbeling
• geen limiet voor netwerkbandbreedte

Basisback-up via rsync (backup_method =rsync)

Voordelen:

• oud en bewezen
• Incrementele back-up
• gegevensdeduplicatie
• netwerkcompressie
• parallelle back-up
• limiet voor netwerkbandbreedte

Nadelen:

• niet de aanbevolen (door de auteurs) manier

WAL-overdracht via WAL-archivering (via rsync)

Voordelen:

• eenvoudiger in te stellen

Nadelen:

• Geen RPO=0 (geen gegevensverlies)
• geen manier om te herstellen van langdurige en aanhoudende netwerkstoringen

WAL-overdracht via WAL-archivering (via barman-wal-archive / put-wal)

Voordelen:

• de nieuwste en aanbevolen manier (geïntroduceerd in 2.6)
• betrouwbaarder/veiliger dan rsync

Nadelen:

• Geen RPO=0 (geen gegevensverlies)
• nog steeds geen manier om te herstellen van langdurige en aanhoudende netwerkstoringen

WAL-overdracht via WAL-streaming met replicatieslot (via pg_receivewal)

Voordelen:

• moderner (en aanbevolen)
• RPO=0 (geen gegevensverlies) in synchrone modus

Nadelen:

• altijd geassocieerd met replicatieslot. Kan groeien in geval van netwerkstoringen

Dus hoewel pg_basebackup (postgres-methode) de toekomst lijkt voor pgbarman, komen in werkelijkheid alle mooie functies met de rsync-methode. Dus laten we alle functies van Barman in meer detail opsommen:

• Bewerking op afstand (back-ups/herstel)
• Incrementele back-ups. Een van de geweldige functies van barman, incrementele back-ups zijn gebaseerd op een vergelijking op bestandsniveau van de databasebestanden met die van de laatste back-up in de catalogus. In barman verwijst de term "differentieel" naar een ander concept:volgens barman-terminologie is een differentiële back-up de laatste back-up + de individuele wijzigingen van de laatste back-up. Barman-documenten zeggen dat ze differentiële back-ups bieden via WAL's. Barman incrementele back-ups werken op bestandsniveau, wat betekent dat als een bestand wordt gewijzigd, het hele bestand wordt overgedragen. Dit is net als pgbackrest en in tegenstelling tot sommige andere aanbiedingen zoals pg_probackup of BART die differentiële/incrementele back-ups op blokniveau ondersteunen. Barman incrementele back-ups worden gespecificeerd via:reuse_backup =link of kopieer. Door "kopie" te definiëren, bereiken we een kortere back-uptijd omdat alleen de gewijzigde bestanden worden overgedragen en geback-upt, maar nog steeds geen vermindering van de ruimte omdat de ongewijzigde bestanden worden gekopieerd van de vorige back-up. Door "link" te definiëren, worden de ongewijzigde bestanden hard gekoppeld (niet gekopieerd) vanaf de laatste back-up. Zo realiseren we zowel tijdsbesparing als ruimtebesparing. Ik wil hier op geen enkele manier meer verwarring in brengen, maar in werkelijkheid zijn incrementele back-ups van barman direct vergelijkbaar met incrementele back-ups van pgbackrest, aangezien barman een incrementele back-up effectief behandelt als een volledige back-up (via link of kopie). Dus in beide systemen behandelt een incrementele back-up de bestanden die zijn gewijzigd sinds de laatste back-up. Met betrekking tot differentiële back-ups betekent dit echter iets anders in elk van de bovengenoemde systemen, zoals we hieronder zullen zien.
• Back-up vanuit stand-by. Barman biedt de mogelijkheid om het grootste deel van de basisback-upbewerkingen uit te voeren vanuit een stand-bymodus, waardoor de primaire back-up wordt bevrijd van de toegevoegde IO-belasting. Houd er echter rekening mee dat de WAL's nog steeds van de primaire moeten komen. Het maakt niet uit of je archive_command of WAL-streaming via replicatieslots gebruikt, je kunt deze taak nog niet (op het moment van schrijven met barman in versie 2.6) naar de stand-by verplaatsen.
• parallelle taken voor back-up en herstel
• Een uitgebreide en uitgebreide set bewaarinstellingen op basis van:
  • Redundantie (aantal back-ups dat moet worden bewaard)
  • Herstelvenster (hoe terug in het verleden moeten de back-ups worden bewaard)
  Naar mijn mening vanuit gebruikersperspectief is het bovenstaande geweldig. De gebruiker kan de link hergebruik_backup =en een herstelvenster definiëren en barman (zijn cron-taak) de rest laten doen. Geen diff/incr/full etc back-ups om je zorgen over te maken of om te plannen of te beheren. Het systeem (barman) doet gewoon het juiste op een transparante manier.
• Uw eigen hook-scripts voor/na het evenement programmeren.
• Tafelruimte opnieuw toewijzen

Dat zijn de sterkste punten van barman. En echt, dit is bijna meer dan de gemiddelde DBA zou vragen van een back-up- en hersteltool. Er zijn echter enkele punten die beter kunnen:

• De mailinglijst is niet zo actief en de beheerders schrijven of beantwoorden zelden vragen
• Geen functie om een ​​mislukte/onderbroken back-up te hervatten
• Replicatieslots of het gebruik van rsync/barman-wal-archive voor archivering zijn niet vergevingsgezind in het geval van een falend netwerk of andere storingen van de back-upsite. In beide gevallen, als de netwerkstoring lang genoeg duurt en de wijzigingen in de DB veel WAL-bestanden waard zijn, zal de primaire last hebben van "geen ruimte meer op het apparaat" en uiteindelijk crashen. (geen goede zaak). Wat hier veelbelovend is, is dat barman nu een alternatieve (voor rsync) manier biedt om WAL's over te dragen, zodat extra bescherming tegen b.v. pg_wal uitputting van de ruimte zou in de toekomst kunnen worden geïmplementeerd, wat samen met back-up-cv de barman echt perfect zou maken, althans voor mij.

pgrugleuning

Pgbackrest is de huidige trend onder de open source back-uptools, voornamelijk vanwege de efficiëntie om met zeer grote hoeveelheden gegevens om te gaan en de extreme zorg die de makers hebben besteed aan het valideren van back-ups via checksums. Op het moment van schrijven is het versie v2.09 en de documenten zijn hier te vinden. De gebruikershandleiding is misschien enigszins verouderd, maar de rest van de documenten is zeer actueel en nauwkeurig. Pgbackrest vertrouwt op WAL-archivering met behulp van zijn eigen archive_command en zijn eigen bestandsoverdrachtmechanisme dat beter en veiliger is dan rsync. Dus pgbackrest is behoorlijk vooruitstrevend omdat het niet de grotere reeks keuzes biedt die barman biedt. Aangezien er geen synchrone modus bij betrokken is, garandeert pgbackrest natuurlijk geen RPO=0 (geen gegevensverlies). Laten we de concepten van pgbackrest beschrijven:

• Een back-up kan zijn:
  • Vol. Een volledige back-up kopieert het hele databasecluster.
  • Differentieel (diff). Een differentiële back-up kopieert alleen de bestanden die zijn gewijzigd sinds de laatste volledige back-up. Voor een succesvol herstel moeten zowel de differentiële back-up als de vorige volledige back-up geldig zijn.
  • Incrementeel (meer). Een incrementele back-up kopieert alleen de bestanden die zijn gewijzigd sinds de laatste back-up (dit kan een volledige back-up zijn, een differentiële of zelfs een incrementele). Net als bij de differentiële back-up, moeten alle eerdere vereiste back-ups (inclusief deze back-up, de laatste diff en de vorige volledige) geldig zijn om een ​​succesvol herstel uit te voeren.
• Een strofe is de definitie van alle vereiste parameters van een PostgreSQL-cluster. Een normale PostgreSQL-server heeft zijn eigen strofe, terwijl back-upservers één strofe hebben voor elk PostgreSQL-cluster waarvan ze een back-up maken.
• Een configuratie is waar informatie over strofen wordt bewaard (meestal /etc/pgbackrest.conf)
• Een repository is waar pgbackrest WAL's en back-ups bewaart

De gebruiker wordt aangemoedigd om de documentatie te volgen zoals de documentatie zelf suggereert, van boven naar beneden. De belangrijkste kenmerken van pgbackrest zijn:

• Parallelle back-up en herstel
• Geen directe SQL-toegang tot de PostgreSQL-server nodig
• Lokale/externe bediening
• Bewaring op basis van:
  • volledige back-upretentie (aantal volledige back-ups om te bewaren)
  • diff back-upretentie (aantal verschillende back-ups om te bewaren)
  Incrementele back-ups hebben geen eigen retentie en verlopen zodra een eerdere back-up verloopt. De gebruiker kan dus een schema definiëren voor het maken van volledige back-ups en een rollende set van verschillende back-ups daartussen.
• Back-up vanuit stand-by. Sommige bestanden moeten nog steeds van de primaire komen, maar de bulkkopie vindt plaats op de standby-modus. Still WAL's moeten afkomstig zijn van de primaire.
• Back-upintegriteit. De mensen achter pgbackrest zijn uiterst voorzichtig als het gaat om de integriteit van de back-ups. Elk bestand wordt tijdens de back-up gecontroleerd en ook na het terugzetten gecontroleerd om er zeker van te zijn dat er geen problematische hardware- of softwarefout kan leiden tot een foutief herstel. Als checksums op paginaniveau zijn ingeschakeld op het PostgreSQL-cluster, worden ze ook voor elk bestand berekend. Bovendien worden voor elk WAL-bestand controlesommen berekend.
• Als compressie is uitgeschakeld en harde koppelingen zijn ingeschakeld, is het mogelijk om het cluster rechtstreeks vanuit de catalogus te openen. Dit is uiterst belangrijk voor grote databases met meerdere TB.
• Hervatten van een mislukte/onderbroken terug. Erg handig bij onbetrouwbare netwerken.
• Deltaherstel:ultrasnel herstel voor grote databases, zonder het hele cluster op te schonen.
• Asynchrone en parallelle WAL-push naar de back-upserver. Dit is een van de sterkste punten van pgbackrest. De PostgreSQL-archiver kopieert alleen naar de spool via archive-push en het zware werk van de overdracht en de verwerking gebeurt in een afzonderlijk pgbackrest-proces. Dit maakt massale WAL-overdrachten mogelijk en zorgt tegelijkertijd voor lage PostgreSQL-reactietijden.
• Tafelruimte opnieuw toewijzen
• Amazon S3-ondersteuning
• Ondersteuning voor maximale WAL-wachtrijgrootte. Wanneer de back-upsite niet beschikbaar is of het netwerk faalt, zal het gebruik van deze optie spotten alsof de archivering succesvol was, waardoor PostgreSQL WAL kan verwijderen om te voorkomen dat pg_wal vol raakt, en zo de pgsql-server te redden van een mogelijke PANIEK.

Dus wat betreft functies legt pgbackrest veel nadruk als het gaat om gegevensvalidatie en prestaties, geen verrassing dat het wordt gebruikt door de grootste en drukste PostgreSQL-installaties. Er is echter één ding dat verbeterd kan worden:

• Het zou erg handig zijn om een ​​meer "liberale" optie te hebben voor wat betreft retentie, d.w.z. een manier bieden om declaratief een bewaarperiode te specificeren en pgbackrest vervolgens de volledige/diff/incr-back-ups te laten afhandelen als dat nodig is.
>

pg_probackup

Pg_proback is een ander veelbelovend hulpmiddel voor back-ups. Het is oorspronkelijk gebaseerd op pg_arman. De nadruk ligt op de prestaties van de back-up. Het is gebaseerd op catalogi en instanties, die erg lijken op de rest van de tools, dus die hebben we. De belangrijkste kenmerken zijn:

• Uitgebreide ondersteuning op back-upniveau, variërend van:
  • Volledige back-ups
  • Incrementeel van drie typen:
    • PAGINA-back-up. Niveauveranderingen gevonden via WAL-scanning. Vereist volledige toegang tot de ononderbroken WAL-reeks sinds de vorige back-up.
    • DELTA-back-up. Alleen gewijzigde pagina's worden naar de back-up gekopieerd. Onafhankelijk van WAL-archivering, belast de server in zekere mate.
    • PTRACK-back-up. Vereist speciale pgsql core patching. Werkt door direct een bitmap bij te houden zodra pagina's worden gewijzigd. Echt snelle back-up met minimale belasting van de server.
• Back-ups kunnen ook worden onderverdeeld in:
  • Autonome back-ups. Die hebben geen vereisten voor WAL buiten de back-up. Geen PITR.
  • Archief back-ups. Die zijn afhankelijk van continue archivering en ondersteunen PITR.
• multithreaded model (in tegenstelling tot barman, pgbackrest en natuurlijk PostgreSQL zelf die een multiprocess-model volgen)
• Consistentie van gegevens en validatie op aanvraag zonder herstel
• Back-up vanuit een stand-by zonder toegang tot de primaire.
• Een expressieve specificatie van het bewaarbeleid waarbij redundantie kan worden gebruikt op een AND-manier samen met venster. Het samenvoegen van back-ups (via samenvoegen) wordt ondersteund door eerdere incrementele back-ups naar volledig te converteren als een manier om ruimte vrij te maken en om een ​​methode te bieden voor een soepele back-uprotatie.

Dus pg_probackup biedt een reeks geweldige functies met de nadruk op prestaties, iets wat grote installaties ten goede zou komen. Er ontbreken echter nog enkele dingen, namelijk:

• Geen enkele officiële release ondersteunt back-ups op afstand. Dit betekent dat pg_probackup op dezelfde host moet draaien als het pgsql-cluster. (Er is een dev-tak die zich bezighoudt met back-up vanaf een externe site en archivering naar een externe back-upserver)
• Geen ondersteuning voor een mislukte back-up-cv.

We kunnen de bovenstaande paragrafen samenvatten met een functiematrix zoals hieronder.

Clusterbeheer

ClusterControl biedt de functionaliteit om ofwel een onmiddellijke back-up te genereren of om er een te plannen, en de taak op een eenvoudige en snelle manier te automatiseren.

We kunnen kiezen tussen twee back-upmethoden, pgdump (logisch) en pg_basebackup (binair). We kunnen ook specificeren waar de back-ups moeten worden opgeslagen (op de databaseserver, op de ClusterControl-server of in de cloud), het compressieniveau en de codering.

Met ClusterControl kunnen we ook de Point-in-Time Recovery-functie en back-upverificatie gebruiken om de gegenereerde back-up te valideren.