Den aktuelle tilstand af Open Source Backup Management til PostgreSQL

Der er mange måder at tage backup af en PostgreSQL-klynge på. Der er flere artikler og blogs, som præsenterer de forskellige teknologier, hvormed vi kan gemme vores dyrebare data i PostgreSQL. Der er logiske backupløsninger, fysisk backup på OS-niveau, på filsystemniveau og så videre. Her i denne blog vil vi ikke dække den teoretiske del, som er tilstrækkeligt dækket af forskellige blogs og artikler samt den officielle dokumentation.

Denne blog fokuserer på status for de forskellige tilgængelige værktøjer og løsninger og et forsøg på at præsentere en grundig sammenligning baseret på erfaringer fra det virkelige liv. Denne artikel forsøger på ingen måde at promovere noget specifikt produkt, jeg kan virkelig godt lide alle de værktøjer, løsninger og teknologier, der er beskrevet i denne blog. Målet her er at notere deres styrker, deres svagheder og at vejlede slutbrugeren til, hvilket værktøj der bedst passer til hans/hendes miljø, infrastruktur og specifikke krav. Her er en fin artikel, der beskriver sikkerhedskopieringsværktøjer til PostgreSQL på forskellige niveauer.

Jeg vil ikke beskrive, hvordan man bruger de forskellige værktøjer i denne blog, da denne info er dokumenteret i ovenstående blog og også i de officielle dokumenter samt andre ressourcer over nettet. Men jeg vil beskrive fordele og ulemper, som jeg oplevede dem i praksis. I denne blog beskæftiger vi os udelukkende med klassiske PITR-baserede fysiske PostgreSQL-sikkerhedskopier afhængig af:

• pg_basebackup eller pg_start_backup()/pg_stop_backup
• fysisk kopi
• arkivering af WAL'er eller streaming-replikering

Der er flere fine produkter og løsninger, nogle er open source og gratis at bruge, mens andre er kommercielle. Så vidt jeg ved, er disse:

• pgbarman af 2. kvadrant (gratis)
• pgryglæn (gratis)
• pg_probackup af Postgres Professional (gratis)
• BART af EDB (kommerciel)

Jeg havde ikke mulighed for at prøve BART, da den kører på varianter af Linux, som jeg ikke bruger. I denne blog vil jeg inkludere mine egne tanker og indtryk, mens jeg interagerer med de respektive forfattere/samfund/vedligeholdere af hver løsning, da dette er et meget vigtigt aspekt, som normalt bliver undervurderet i begyndelsen. En lille smule terminologi for bedre at forstå de forskellige udtryk i hvert af værktøjerne:

pgbarman

Pgbarman eller bare barman er det ældste af disse værktøjer. Den seneste udgivelse er 2.6 (udgivet, mens jeg havde denne blog i gang! hvilket er gode nyheder).

Pgbarman understøtter basis backup via to metoder:

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

og WAL-overførsel via:

• WAL-arkivering
  • via rsync
  • via barman-wal-archive / put-wal
• WAL via streaming-replikering med replikeringsplads
  • Asynkron
  • Synkron

Dette giver os 8 ud af boksen kombinationer, som vi kan bruge barmand. Hver har sine fordele og ulemper.

Base backup via pg_basebackup (backup_method =postgres)

Fordele:

• den nyeste/moderne måde
• afhængig af dokumenteret kerne-PostgreSQL-teknologi
• anbefalet af de officielle dokumenter

Ulemper:

• ingen trinvis sikkerhedskopiering
• ingen parallel backup
• ingen netværkskomprimering
• ingen datadeduplikering
• ingen netværksbåndbreddegrænse

Basis backup via rsync (backup_method =rsync)

Fordele:

• gammel og gennemprøvet
• Inkrementel sikkerhedskopiering
• data deduplikering
• netværkskomprimering
• parallel backup
• grænse for netværksbåndbredde

Ulemper:

• ikke den anbefalede (af forfatterne) måde

WAL-overførsel via WAL-arkivering (via rsync)

Fordele:

• enklere at konfigurere

Ulemper:

• Ingen RPO=0 (nul datatab)
• ingen måde at komme sig efter lange og vedvarende netværksfejl

WAL-overførsel via WAL-arkivering (via barman-wal-archive / put-wal)

Fordele:

• den seneste og anbefalede måde (introduceret i 2.6)
• mere pålidelig/sikker end rsync

Ulemper:

• Ingen RPO=0 (nul datatab)
• stadig ingen måde at komme sig efter lange og vedvarende netværksfejl

WAL-overførsel via WAL-streaming med replikeringsslot (via pg_receivewal)

Fordele:

• mere moderne (og anbefalet)
• RPO=0 (nul datatab) i synkron tilstand

Ulemper:

• altid forbundet med replikeringsplads. Kan vokse i tilfælde af netværksfejl

Så mens pg_basebackup (postgres-metoden) virker som fremtiden for pgbarman, kommer alle de smarte funktioner i virkeligheden med rsync-metoden. Så lad os liste alle funktionerne i Barman mere detaljeret:

• Fjernbetjening (sikkerhedskopiering/gendannelse)
• Inkrementelle sikkerhedskopier. En af de store egenskaber ved barman, inkrementelle sikkerhedskopier er baseret på filniveausammenligningen af ​​databasefilerne med dem fra den sidste sikkerhedskopi i kataloget. I barmand refererer udtrykket "differentiel" til et andet koncept:Med barmands terminologi er en differentiel backup den sidste backup + de individuelle ændringer fra den sidste backup. Barman-dokumenter siger, at de giver differentielle sikkerhedskopier via WAL'er. Barman inkrementelle sikkerhedskopier fungerer på filniveau, hvilket betyder, at hvis en fil ændres, overføres hele filen. Dette er ligesom pgbackrest og i modsætning til nogle andre tilbud som pg_probackup eller BART, der understøtter differentiel/inkrementel sikkerhedskopiering på blokniveau. Barman trinvise sikkerhedskopier er specificeret via:genbrug_sikkerhedskopiering =link eller kopi. Ved at definere "kopi" opnår vi reduceret tid på sikkerhedskopieringen, da kun de ændrede filer overføres og sikkerhedskopieres, men stadig ingen reduktion af plads, da de uændrede filer kopieres fra den tidligere sikkerhedskopi. Ved at definere "link", så er de uændrede filer hardlinket (ikke kopieret) fra den sidste backup. På denne måde opnår vi både tidsreduktion og pladsreduktion. Jeg ønsker ikke på nogen måde at skabe mere forvirring i dette, men i virkeligheden er barman inkrementelle backups direkte sammenlignelige med pgbackrest incremental backups, da barman behandler (via link eller kopi) en trinvis backup effektivt som en fuld backup. Så i begge systemer behandler en trinvis sikkerhedskopiering de filer, der er blevet ændret siden sidste sikkerhedskopiering. Men med hensyn til differentielle sikkerhedskopier betyder det en anden ting i hvert af de førnævnte systemer, som vi vil se nedenfor.
• Sikkerhedskopiering fra standby. Barman giver mulighed for at udføre hovedparten af ​​basis-backup-operationerne fra en standby og dermed frigøre den primære fra den tilføjede IO-belastning. Bemærk dog, at WAL'erne stadig skal komme fra den primære. Det er ligegyldigt, om du bruger archive_command eller WAL-streaming via replikeringsslots, du kan endnu (i skrivende stund med barman på version 2.6) ikke overføre denne opgave til standby.
• parallelle job til sikkerhedskopiering og gendannelse
• Et rigt og omfattende sæt af opbevaringsindstillinger baseret på enten:
  • Redundans (antal sikkerhedskopier at beholde)
  • Gendannelsesvindue (hvordan tilbage i fortiden skal sikkerhedskopierne opbevares)
  Efter min mening fra et brugerperspektiv er ovenstående fantastisk. Brugeren kan definere reuse_backup =link og et gendannelsesvindue og lade barman (dens cron job) tage sig af resten. Ingen diff/incr/full etc backups at bekymre sig om eller planlægge eller administrere. Systemet (barmanden) gør bare det rigtige gennemsigtigt.
• Programmering af dine egne pre/post event hook scripts.
• Tablespace-omlægning

Det er barmandens bedste styrker. Og dette er virkelig næsten mere end den gennemsnitlige DBA ville bede om fra et backup- og gendannelsesværktøj. Der er dog nogle punkter, der kunne være bedre:

• Mailinglisten er ikke så aktiv, og vedligeholdere skriver eller besvarer sjældent spørgsmål
• Ingen funktion til at genoptage en mislykket/afbrudt sikkerhedskopiering
• Replikeringspladser eller brugen af ​​rsync/barman-wal-archive til arkivering er ikke tilgivende i tilfælde af fejl på netværket eller andre fejl på sikkerhedskopieringsstedet. I begge tilfælde, hvis netværksafbrydelsen er lang nok, og ændringerne i DB'en er en masse WAL-filer værd, vil den primære lide af "ingen plads tilbage på enheden" og vil til sidst gå ned. (ikke en god ting). Det lovende her er, at barman nu giver en alternativ (til rsync) måde at overføre WAL'er på, så yderligere beskyttelse mod f.eks. pg_wal pladsudtømning kan blive implementeret i fremtiden, hvilket sammen med backup-cv virkelig ville gøre barman perfekt, i det mindste for mig.

pg ryglæn

Pgbackrest er den nuværende trend blandt open source-sikkerhedskopieringsværktøjerne, hovedsageligt fordi dens effektivitet til at håndtere meget store datamængder og den ekstreme omhu, som dens skabere lægger i validering af sikkerhedskopier via kontrolsummer. Når dette skrives, er den på version v2.09, og dokumenterne findes her. Brugervejledningen kan være lidt forældet, men resten af ​​dokumenterne er meget opdaterede og nøjagtige. Pgbackrest er afhængig af WAL-arkivering ved hjælp af sin egen archive_command og sin egen filoverførselsmekanisme, som er bedre og sikrere end rsync. Så pgbackrest er ret fremme, da det ikke giver det større sæt af valgmuligheder, som barman giver. Da der ikke er nogen synkron tilstand involveret, garanterer pgbackrest naturligvis ikke RPO=0 (nul datatab). Lad os beskrive pgbackrests koncepter:

• En sikkerhedskopi kan være:
  • Fuld. En fuld sikkerhedskopi kopierer hele databaseklyngen.
  • Differential (diff). En differentiel sikkerhedskopi kopierer kun de filer, der er blevet ændret siden den sidste fulde sikkerhedskopiering. For en vellykket gendannelse skal både den differentielle backup og den tidligere fulde backup være gyldige.
  • Inkrementel (incr). En trinvis sikkerhedskopi kopierer kun de filer, der er blevet ændret siden sidste sikkerhedskopiering (som kan være en fuld sikkerhedskopi, en differentiel eller endda en trinvis). På samme måde som den differentielle sikkerhedskopiering skal alle tidligere nødvendige sikkerhedskopier (inklusive denne sikkerhedskopi, den seneste diff og den forrige fulde) være gyldige for at udføre en vellykket gendannelse.
• En strofe er definitionen af ​​alle nødvendige parametre i en PostgreSQL-klynge. En PostgreSQL-server har normalt sin egen strofe, hvorimod backupservere vil have én strofe for hver PostgreSQL-klynge, som de sikkerhedskopierer.
• En konfiguration er, hvor information om strofer opbevares (normalt /etc/pgbackrest.conf)
• Et lager er det sted, hvor pgbackrest opbevarer WAL'er og sikkerhedskopier

Brugeren opfordres til at følge dokumentationen, som dokumentationen selv antyder, fra top til bund. De vigtigste funktioner ved pgbackrest er:

• Parallel sikkerhedskopiering og gendannelse
• Ingen direkte SQL-adgang til PostgreSQL-serveren nødvendig
• Lokal/fjernbetjening
• Retention baseret på:
  • opbevaring af fuld sikkerhedskopi (antal fulde sikkerhedskopier, der skal beholdes)
  • opbevaring af diff-backup (antal diff-sikkerhedskopier, der skal beholdes)
  Inkrementelle sikkerhedskopier har ikke deres egen opbevaring og udløber, så snart en tidligere sikkerhedskopiering udløber. Så brugeren kan definere en tidsplan for at tage fuld sikkerhedskopiering og et rullende sæt af forskellige sikkerhedskopier mellem dem.
• Sikkerhedskopiering fra standby. Nogle filer skal stadig komme fra den primære, men massekopieringen foregår på standby. Stadig WAL'er skal stamme fra den primære.
• Sikkerhedskopieringsintegritet. Folkene bag pgbackrest er ekstremt forsigtige, når det kommer til sikkerhedskopiernes integritet. Hver fil checksummeres ved sikkerhedskopiering og kontrolleres også efter gendannelsen for at sikre, at ingen problematisk hardware- eller softwarefejl kan resultere i en defekt gendannelse. Hvis kontrolsummer på sideniveau er aktiveret på PostgreSQL-klyngen, beregnes de også for hver fil. Derudover beregnes kontrolsummer for hver WAL-fil.
• Hvis komprimering er deaktiveret, og hårde links er aktiveret, er det muligt at hente klyngen frem direkte fra kataloget. Dette er ekstremt vigtigt for store databaser med flere TB.
• Genoptagelse af en mislykket/afbrudt tilbage. Meget praktisk i tilfælde af upålidelige netværk.
• Delta-gendannelse:Ultrahurtig gendannelse til store databaser uden at rense hele klyngen.
• Asynkron &Parallel WAL push til backupserveren. Dette er et af de stærkeste punkter ved pgbackrest. PostgreSQL-arkiveringsværktøjet kopierer kun til spoolen via archive-push, og det tunge arbejde med overførslen og behandlingen sker i en separat pgbackrest-proces. Dette giver mulighed for massive WAL-overførsler og samtidig sikre lave PostgreSQL-svartider.
• Tablespace-omlægning
• Amazon S3-understøttelse
• Understøttelse af maks. WAL-køstørrelse. Når sikkerhedskopieringsstedet er nede, eller netværket svigter, vil brugen af ​​denne mulighed håne, som om arkiveringen var vellykket, hvilket tillader PostgreSQL at slette WAL, der forhindrer opfyldning af pg_wal, og dermed redde pgsql-serveren fra en potentiel PANIK.

Så funktionsmæssigt lægger pgbackrest meget vægt, når det kommer til datavalidering og ydeevne, ingen overraskelse, at det bruges af de største og travleste PostgreSQL-installationer. Der er dog én ting, der kunne forbedres:

• Det ville virkelig være praktisk at have en mere "liberal" mulighed, hvad angår opbevaring, dvs. give en måde at deklarativt angive en opbevaringsperiode og derefter lade pgbackrest håndtere fuld/forskel/incr backup efter behov.

pg_probackup

Pg_proback er et andet lovende værktøj til sikkerhedskopiering. Det er oprindeligt baseret på pg_arman. Dens vægt er på sikkerhedskopieringens ydeevne. Det er baseret på kataloger og instanser, der ligner resten af ​​værktøjerne meget, så vi har. Dens vigtigste funktioner omfatter:

• Rig support på sikkerhedskopieringsniveau spænder fra:
  • Fuld sikkerhedskopiering
  • Inkrementel af tre typer:
    • PAGE backup. Niveauændringer fundet via WAL-scanning. Kræver fuld adgang til den uafbrudte WAL-sekvens siden den forrige sikkerhedskopiering.
    • DELTA backup. Kun ændrede sider kopieres til backup. Uafhængigt af WAL-arkivering, lægger en vis belastning på serveren.
    • PTRACK backup. Kræver speciel pgsql core patching. Fungerer ved at vedligeholde en bitmap i farten, så snart siderne er ændret. Virkelig hurtig backup med minimal belastning på serveren.
• Sikkerhedskopier kan også opdeles i:
  • Autonome sikkerhedskopier. De har ingen krav til WAL uden for backup. Ingen PITR.
  • Arkiver sikkerhedskopier. De er afhængige af kontinuerlig arkivering og understøtter PITR.
• multithreaded model (i modsætning til barman, pgbackrest og selvfølgelig PostgreSQL selv, som følger en multiproces model)
• Datakonsistens og on demand-validering uden gendannelse
• Sikkerhedskopiering fra en standby uden adgang til den primære.
• En udtryksfuld fastholdelsespolitikspecifikation, hvor redundans kan bruges på en OG-måde sammen med vindue. Sammenlægning af sikkerhedskopier (via fletning) understøttes ved at konvertere tidligere trinvise sikkerhedskopier til fuld som en måde at frigøre plads og for at give en metode til jævn backup-rotation.

Så pg_probackup giver et sæt fantastiske funktioner med vægt på ydeevne, noget som ville gavne store installationer. Der mangler dog stadig nogle ting, nemlig:

• Ingen officiel udgivelse understøtter fjernsikkerhedskopiering. Det betyder, at pg_probackup skal køre på samme vært som pgsql-klyngen. (Der er en udviklergren, som beskæftiger sig med backup fra et eksternt websted samt arkivering til en ekstern backup-server)
• Ingen understøttelse af et mislykket backup-cv.

Vi kan opsummere ovenstående afsnit med en funktionsmatrix som nedenstående.

ClusterControl

ClusterControl giver funktionaliteten til enten at generere en øjeblikkelig backup eller at planlægge en og automatisere opgaven på en enkel og hurtig måde.

Vi kan vælge mellem to backup metoder, pgdump (logisk) og pg_basebackup (binær). Vi kan også angive, hvor sikkerhedskopierne skal opbevares (på databaseserveren, på ClusterControl-serveren eller i skyen), komprimeringsniveauet og kryptering.

Med ClusterControl kan vi også bruge Point-in-Time Recovery-funktionen og backupverifikation til at validere den genererede backup.