Sikkerhedskopier - en af de vigtigste ting at tage sig af, mens du administrerer databaser. Det siges, at der er to typer mennesker - dem, der sikkerhedskopierer deres data, og dem, der vil sikkerhedskopiere deres data. I dette blogindlæg vil vi diskutere god praksis omkring sikkerhedskopiering og vise dig, hvordan du kan bygge et pålideligt backupsystem ved hjælp af ClusterControl.
Vi vil se, hvordan ClusterControl's giver dig centraliseret backupstyring til MySQL, MariaDB, MongoDB og PostgreSQL. Det giver dig varme sikkerhedskopier af store datasæt, punkt-i-tidsgendannelse, datakryptering i hvile og under transport, dataintegritet via automatisk gendannelsesverifikation, cloud-backups (AWS, Google og Azure) til Disaster Recovery, opbevaringspolitikker for at sikre overholdelse og automatiske alarmer og rapportering.
Sikkerhedskopieringstyper
Der er to hovedtyper af backup, som vi kan lave i ClusterControl:
- Logisk sikkerhedskopiering - sikkerhedskopiering af data gemmes i et menneskelæsbart format som SQL
- Fysisk backup - backup indeholder binære data
Begge komplementerer hinanden - logisk backup giver dig mulighed for (mere eller mindre let) at hente op til en enkelt række data. Fysiske sikkerhedskopier ville kræve mere tid for at opnå det, men på den anden side giver de dig mulighed for at gendanne en hel vært meget hurtigt (noget, der kan tage timer eller endda dage, når du bruger logisk sikkerhedskopiering).
ClusterControl understøtter backup til MySQL/MariaDB/Percona Server, PostgreSQL og MongoDB.
Planlæg sikkerhedskopiering
At starte en sikkerhedskopi i ClusterControl er enkel og effektiv ved hjælp af en guide. Planlægning af en sikkerhedskopi giver brugervenlighed og tilgængelighed til andre funktioner såsom kryptering, automatisk test/bekræftelse af sikkerhedskopiering eller skyarkivering.
Tilgængelige planlagte sikkerhedskopier vil blive vist på fanen Planlagte sikkerhedskopier som vist på billedet nedenfor:
Som en god praksis for at planlægge en sikkerhedskopiering skal du allerede have din definerede backup-opbevaring, og en daglig backup anbefales. Det afhænger dog også af de data, du har brug for, den trafik, du kan forvente, og tilgængeligheden af dataene, når du har brug for dem, især under datagendannelse, hvor data ved et uheld er blevet slettet eller en disk-korruption - hvilket er uundgåeligt. Der er også situationer, hvor datatab er reproducerbart eller kan duplikeres manuelt, som f.eks. rapportgenerering, thumbnails eller cachelagrede data. Selvom spørgsmålet afhænger af, hvor øjeblikkeligt du har brug for dem, når der sker en katastrofe; Når det er muligt, vil du gerne tage både mysqldump og xtrabackup backups på daglig basis for at MySQL udnytter den logiske og fysiske backup tilgængelighed. For at dække endnu flere baser kan du planlægge flere trinvise xtrabackup-kørsler om dagen. Dette kan spare noget diskplads, disk I/O eller endda CPU I/O end at tage en fuld sikkerhedskopi.
I ClusterControl kan du nemt planlægge disse forskellige typer sikkerhedskopier. Der er et par indstillinger at tage stilling til. Du kan gemme en sikkerhedskopi på controlleren eller lokalt på databasenoden, hvor sikkerhedskopien er taget. Du skal beslutte dig for, hvor sikkerhedskopien skal gemmes, og hvilke databaser du vil sikkerhedskopiere - alle datasæt eller separate skemaer? Se billedet nedenfor:
Den avancerede indstilling ville drage fordel af en cron-lignende konfiguration for mere granularitet. Se billedet nedenfor:
Når der opstår en fejl, håndterer ClusterControl disse problemer effektivt og producerer logfiler til yderligere diagnose af sikkerhedskopieringsfejlen.
Afhængigt af den sikkerhedskopieringstype, du har valgt, er der separate indstillinger, der skal konfigureres. For Xtrabackup og Galera Cluster har du muligvis mulighed for at vælge, hvilke indstillinger din fysiske sikkerhedskopiering skal gælde, når du kører. Se nedenfor:
- Brug komprimering
- Kompressionsniveau
- Afsynkroniseringsknude under backup
- Backuplåse
- Lås DDL pr. tabel
- Xtrabackup Parallel Copy Threads
- Netværksstreaming-gashastighed (MB/s)
- Brug PIGZ til parallel gzip
- Aktiver kryptering
- Retention
Du kan se, på billedet nedenfor, hvordan du kan markere mulighederne i overensstemmelse hermed, og der er værktøjstip-ikoner, som giver flere oplysninger om de muligheder, du gerne vil udnytte til din sikkerhedskopieringspolitik.
Afhængigt af din sikkerhedskopieringspolitik kan ClusterControl skræddersyes i overensstemmelse med bedste praksis for at tage dine sikkerhedskopier, som er tilgængelige opdateret. Når du har defineret din sikkerhedskopieringspolitik, forventes det, at du skal have din nødvendige opsætning tilgængelig fra hardware til software til sky, holdbarhed, høj tilgængelighed eller skalerbarhed.
Når du tager sikkerhedskopier på en Galera-klynge, er det en god praksis at indstille Galera-noden wsrep_desync=ON, mens sikkerhedskopieringen kører. Dette vil fjerne noden fra at deltage i Flow Control og vil beskytte hele klyngen mod replikeringsforsinkelse, især hvis dine data, der skal sikkerhedskopieres, er store. I ClusterControl skal du huske på, at dette også kan fjerne din mål-backup-knude fra belastningsbalanceringssættet. Dette gælder især, hvis du bruger HAProxy, ProxySQL eller MaxScale proxyer. Hvis du har opsat advarselsadministrator i tilfælde af, at noden desynkroniseres, kan du slå fra i den periode, hvor sikkerhedskopieringen er blevet udløst.
En anden populær måde at minimere påvirkningen af en sikkerhedskopi på en Galera Cluster eller en replikeringsmaster er at implementere en replikeringsslave og derefter bruge den som en kilde til sikkerhedskopier - på denne måde vil Galera Cluster ikke blive påvirket på noget tidspunkt, da sikkerhedskopien på slave er afkoblet fra klyngen.
Du kan implementere en sådan slave med blot et par klik ved hjælp af ClusterControl. Se billedet nedenfor:
og når du klikker på den knap, kan du vælge, hvilke noder du vil konfigurere en slave på. Sørg for, at nodernes binære logning er aktiveret. Aktivering af den binære log kan også gøres gennem ClusterControl, som tilføjer flere muligheder for at administrere din ønskede master. Se billedet nedenfor:
og du kan også opsætte eksisterende replikeringsslave,
For PostgreSQL har du muligheder for at sikkerhedskopiere enten logiske eller fysiske sikkerhedskopier. I ClusterControl kan du udnytte dine PostgreSQL-sikkerhedskopier ved at vælge pg_dump eller pg_basebackup. pg_basebackup vil ikke virke for versioner ældre end 9.3.
For MongoDB tilbyder ClusterControl mongodump eller mongodb konsistent. Du skal muligvis være opmærksom på, at mongodb consistent ikke understøtter RHEL 7, men du kan muligvis installere det manuelt.
Som standard vil ClusterControl liste en rapport for alle de sikkerhedskopier, der er blevet taget, vellykkede eller mislykkede. Se nedenfor:
Du kan tjekke listen over sikkerhedskopieringsrapporter, der er blevet oprettet eller planlagt ved hjælp af ClusterControl. På listen kan du se loggene for yderligere undersøgelse og diagnose. For eksempel, hvis sikkerhedskopieringen blev afsluttet korrekt i henhold til din ønskede sikkerhedskopieringspolitik, om komprimering og kryptering er indstillet korrekt, eller om den ønskede sikkerhedskopieringsdatastørrelse er korrekt. Dette er en god måde at foretage et hurtigt fornuftstjek - hvis dit datasæt er omkring 1 GB størrelse, er der ingen måde, en fuld sikkerhedskopi kan være så lille som 100 KB - noget må være gået galt på et tidspunkt.
Katastrofegendannelse
Lagring af sikkerhedskopier i klyngen (enten direkte på en databasenode eller på ClusterControl-værten) er praktisk, når du hurtigt vil gendanne dine data:alle sikkerhedskopieringsfiler er på plads og kan dekomprimeres og gendannes med det samme. Når det kommer til Disaster Recovery (DR), er dette muligvis ikke den bedste mulighed. Forskellige problemer kan opstå - servere kan gå ned, netværket fungerer muligvis ikke pålideligt, selv hele datacentre er muligvis ikke tilgængelige på grund af en form for udfald. Det kan ske, uanset om du arbejder med en mindre tjenesteudbyder med et enkelt datacenter eller en global leverandør som Amazon Web Services. Det er derfor ikke sikkert at opbevare alle dine æg i en enkelt kurv – du bør sørge for at have en kopi af din backup gemt et eksternt sted. ClusterControl understøtter Amazon S3, Google Storage og Azure Cloud Storage.
For dem, der gerne vil implementere deres egne DR-politikker, er ClusterControl-sikkerhedskopier gemt i et pænt struktureret bibliotek. Du har også mulighed for at uploade din backup til skyen. Se billedet nedenfor:
Du kan vælge og uploade til Amazon Web Services, Google Cloud og Microsoft Azure. Se billedet nedenfor:
Som en god praksis, når du arkiverer dine databasesikkerhedskopier, skal du sørge for, at din skydestination er baseret på samme region som dine databaseservere, eller i det mindste den nærmeste. Sørg for, at den tilbyder høj tilgængelighed, holdbarhed og skalerbarhed; da du skal overveje, hvor ofte og øjeblikkeligt du har brug for dine data.
Ud over at oprette en logisk eller fysisk sikkerhedskopi til din DR, kan oprettelse af et komplet øjebliksbillede af dine data (f.eks. ved hjælp af LVM Snapshot, Amazon EBS Snapshots eller Volume Snapshots, hvis du bruger Veritas filsystem) på den bestemte node øge din backupgendannelse. Du kan også bruge WAL (til Postgres) til din Point In Time Recovery (PITR) eller dine MySQL binære logfiler til din PITR. Du skal derfor overveje, at du muligvis skal oprette din egen arkivering til din PITR. Så det er helt fint at bygge og implementere dit eget sæt scripts og håndtere DR i overensstemmelse med dine nøjagtige krav.
En anden fantastisk måde at implementere en Disaster Recovery-politik på er at bruge en asynkron replikeringsslave - noget vi nævnte tidligere i dette blogindlæg. Du kan installere en sådan asynkron slave på en fjernplacering, måske et andet datacenter, og derefter bruge det til at lave sikkerhedskopier og gemme dem lokalt på den pågældende slave. Selvfølgelig vil du gerne tage en lokal sikkerhedskopi af din klynge for at have den rundt lokalt, hvis du skal gendanne klyngen. Det kan tage lang tid at flytte data mellem datacentre, så det kan spare dig for noget tid at have en sikkerhedskopifiler til rådighed lokalt. I tilfælde af at du mister adgangen til din hovedproduktionsklynge, har du muligvis stadig adgang til slaven. Denne opsætning er meget fleksibel - for det første har du en kørende MySQL-vært med dine produktionsdata, så det burde ikke være for svært at implementere hele din applikation på DR-webstedet. Du vil også have sikkerhedskopier af dine produktionsdata, som du kan bruge til at udskalere dit DR-miljø.
Til sidst og vigtigst af alt, forbliver en sikkerhedskopi, der ikke er blevet testet, en ubekræftet sikkerhedskopi, alias Schroedinger Backup. For at sikre, at du har en fungerende sikkerhedskopi, skal du udføre en gendannelsestest. ClusterControl tilbyder en måde til automatisk at bekræfte og teste din backup.
Vi håber, at dette giver dig nok information til at bygge en sikker og pålidelig sikkerhedskopieringsprocedure for dine open source-databaser.