I de sidste fire indlæg i blogserien dækkede vi implementering af klynge/replikering (MySQL/Galera, MySQL-replikering, MongoDB &PostgreSQL), styring og overvågning af dine eksisterende databaser og klynger, præstationsovervågning og sundhed og i det sidste indlæg, hvordan du gør din opsætning yderst tilgængelig gennem HAProxy og ProxySQL.
Så nu hvor du har dine databaser kørende og meget tilgængelige, hvordan sikrer du dig så, at du har sikkerhedskopier af dine data?
Du kan bruge sikkerhedskopier til flere ting:katastrofegendannelse, til at levere produktionsdata til at teste mod udvikling eller endda til at klargøre en slaveknude. Dette sidste tilfælde er allerede dækket af ClusterControl. Når du tilføjer en ny (replika) node til din replikeringsopsætning, laver ClusterControl en sikkerhedskopi/snapshot af masternoden og bruger den til at bygge replikaen. Den kan også bruge en eksisterende backup til at iscenesætte replikaen, hvis du vil undgå den ekstra belastning på masteren. Når sikkerhedskopien er blevet udtrukket, forberedt og databasen er oppe at køre, vil ClusterControl automatisk konfigurere replikering.
Oprettelse af en øjeblikkelig sikkerhedskopi
I det væsentlige er oprettelse af en sikkerhedskopi det samme for Galera, MySQL-replikering, PostgreSQL og MongoDB. Du kan finde sikkerhedskopieringssektionen under ClusterControl> Backup og som standard vil du se en liste over oprettede backup af klyngen (hvis nogen). Ellers vil du se en pladsholder til at oprette en sikkerhedskopi:
Herfra kan du klikke på knappen "Opret sikkerhedskopi" for at lave en øjeblikkelig sikkerhedskopiering eller planlægge en ny sikkerhedskopiering:
Alle oprettede sikkerhedskopier kan også uploades til skyen ved at skifte "Upload sikkerhedskopiering til skyen", forudsat at du angiver fungerende cloud-legitimationsoplysninger. Som standard vil alle sikkerhedskopier, der er ældre end 31 dage, blive slettet (kan konfigureres via indstillinger for sikkerhedskopiering), eller du kan vælge at beholde det for evigt eller definere en tilpasset periode.
"Create Backup" og "Schedule Backup" deler lignende muligheder undtagen planlægningsdelen og inkrementelle sikkerhedskopieringsmuligheder for sidstnævnte. Derfor vil vi se nærmere på Create Backup-funktionen (også kaldet øjeblikkelig backup).
Da alle disse forskellige databaser har forskellige sikkerhedskopieringsværktøjer, er der naturligvis en vis forskel på de muligheder, du kan vælge. For eksempel med MySQL kan du vælge mellem mysqldump og xtrabackup (fuld og inkrementel). For MongoDB understøtter ClusterControl mongodump og mongodb-consistent-backup (beta), mens PostgreSQL, pg_dump og pg_basebackup er understøttet. Hvis du er i tvivl om, hvilken du skal vælge til MySQL, så tjek denne blog om forskellene og use cases for mysqldump og xtrabackup.
Sikkerhedskopiering af MySQL og Galera
Som nævnt i det foregående afsnit kan du lave MySQL-sikkerhedskopier ved at bruge enten mysqldump eller xtrabackup (fuld eller trinvis). I guiden "Opret sikkerhedskopiering" kan du vælge, hvilken vært du vil køre sikkerhedskopieringen på, den placering, hvor du vil gemme sikkerhedskopieringsfilerne, og dens mappe og specifikke skemaer (xtrabackup) eller skemaer og tabeller (mysqldump).
Hvis den node, du sikkerhedskopierer, modtager (produktions)trafik, og du er bange for, at de ekstra diskskrivninger vil blive påtrængende, anbefales det at sende sikkerhedskopierne til ClusterControl-værten ved at vælge "Gem på controller". Dette vil få sikkerhedskopien til at streame filerne over netværket til ClusterControl-værten, og du skal sikre dig, at der er nok plads på denne node, og at streamingporten er åbnet på ClusterControl-værten.
Der er også flere andre muligheder, uanset om du vil bruge komprimering og komprimeringsniveauet. Jo højere komprimeringsniveauet er, jo mindre vil sikkerhedskopieringsstørrelsen være. Det kræver dog højere CPU-brug til komprimering og dekomprimering.
Hvis du ville vælge xtrabackup som metode til backup, ville det åbne op for ekstra muligheder:desync, backup locks, komprimering og xtrabackup parallelle tråde/gzip. Desync-indstillingen er kun anvendelig til at desynkronisere en node fra en Galera-klynge. Backup-låse bruger en ny MDL-låsetype til at blokere opdateringer til ikke-transaktionelle tabeller og DDL-sætninger for alle tabeller, hvilket er mere effektivt til InnoDB-specifik arbejdsbelastning. Hvis du kører på Galera Cluster, anbefales det at aktivere denne mulighed.
Efter at have planlagt en øjeblikkelig sikkerhedskopiering kan du holde styr på forløbet af sikkerhedskopieringsjobbet i Aktivitet> Job :
Når den er færdig, bør du kunne se en ny post under backuplisten.
Sikkerhedskopiering af PostgreSQL
På samme måde som de øjeblikkelige sikkerhedskopier af MySQL kan du køre en sikkerhedskopi på din Postgres-database. Med Postgres backups er der to backup metoder understøttet - pg_dumpall eller pg_basebackup. Vær opmærksom på, at ClusterControl altid udfører en fuld sikkerhedskopiering uanset den valgte backupmetode.
Vi har dækket dette aspekt i disse detaljer i Bliv en PostgreSQL DBA - Logical &Physical PostgreSQL Backups.
Sikkerhedskopiering af MongoDB
For MongoDB understøtter ClusterControl standard mongodump og mongodb-consistent-backup udviklet af Percona. Sidstnævnte er stadig i betaversion, som giver klyngekonsistente punkt-i-tids-sikkerhedskopier af MongoDB, der er egnet til sharded cluster-opsætninger. Da den shardede MongoDB-klynge består af flere replikasæt, et config-replikasæt og shard-servere, er det meget vanskeligt at lave en konsekvent sikkerhedskopiering ved kun at bruge mongodump.
Bemærk, at du i guiden ikke behøver at vælge en databasenode for at blive sikkerhedskopieret. ClusterControl vælger automatisk den sundeste sekundære replika som backup-knudepunkt. Ellers vil den primære blive valgt. Når sikkerhedskopieringen kører, vil den valgte backup-knude være låst, indtil backup-processen er fuldført.
Planlægning af sikkerhedskopier
Nu hvor vi har leget med at lave øjeblikkelige sikkerhedskopier, kan vi nu udvide det ved at planlægge sikkerhedskopierne.
Planlægningen er meget nem at udføre:Du kan vælge, på hvilke dage sikkerhedskopieringen skal foretages, og på hvilket tidspunkt den skal køre.
Til xtrabackup er der en ekstra funktion:inkrementelle sikkerhedskopier. En trinvis sikkerhedskopiering vil kun sikkerhedskopiere de data, der er ændret siden sidste sikkerhedskopiering. Selvfølgelig er de trinvise sikkerhedskopier ubrugelige, hvis der ikke ville være fuld backup som udgangspunkt. Mellem to fulde sikkerhedskopier kan du have så mange trinvise sikkerhedskopier, som du vil. Men det vil tage længere tid at gendanne dem.
Når de er planlagt, skulle jobbet/jobbene blive synlige under fanen "Planlagt sikkerhedskopiering", og du kan redigere dem ved at klikke på knappen "Rediger". Ligesom med de øjeblikkelige sikkerhedskopier, planlægger disse job oprettelsen af en sikkerhedskopi, og du kan holde styr på fremskridtene via fanen Aktivitet.
Sikkerhedskopieringsliste
Du kan finde sikkerhedskopieringslisten under ClusterControl> Backup og dette vil give dig en oversigt over alle sikkerhedskopier på klyngeniveau. Hvis du klikker på hver post, udvides rækken og afsløre flere oplysninger om sikkerhedskopieringen:
Hver backup er ledsaget af en backup-log, når ClusterControl udførte jobbet, som er tilgængelig under knappen "Flere handlinger".
Offsite sikkerhedskopiering i skyen
Da vi nu har en masse sikkerhedskopier gemt på enten databaseværterne eller ClusterControl-værten, vil vi også sikre, at de ikke går tabt i tilfælde af, at vi står over for et totalt nedbrud i infrastrukturen. (f.eks. DC i brand eller oversvømmet) Derfor giver ClusterControl dig mulighed for at gemme eller kopiere dine sikkerhedskopier offsite på skyen. De understøttede cloud-platforme er Amazon S3, Google Cloud Storage og Azure Cloud Storage.
Uploadprocessen sker lige efter, at sikkerhedskopien er oprettet (hvis du skifter til "Upload sikkerhedskopi til skyen"), eller du kan manuelt klikke på skyikonknappen på backuplisten:
Vælg cloud-legitimationsoplysningerne, og angiv sikkerhedskopieringsplaceringen i overensstemmelse hermed:
Gendan og/eller bekræft sikkerhedskopiering
Fra Backup List-grænsefladen kan du gendanne en sikkerhedskopi direkte til en vært i klyngen ved at klikke på knappen "Gendan" for den pågældende sikkerhedskopi eller klikke på knappen "Gendan sikkerhedskopiering":
En god funktion er, at den er i stand til at gendanne en node eller klynge ved hjælp af de fulde og trinvise sikkerhedskopier, da den vil holde styr på den sidste fulde sikkerhedskopiering, der er lavet, og starte den trinvise sikkerhedskopiering derfra. Derefter vil den gruppere en fuld sikkerhedskopi sammen med alle inkrementelle sikkerhedskopier indtil den næste fulde sikkerhedskopi. Dette giver dig mulighed for at gendanne fra den fulde sikkerhedskopi og anvende de trinvise sikkerhedskopier oven på den.
ClusterControl understøtter gendannelse på en eksisterende databasenode eller gendannelse og verifikation på en ny selvstændig vært:
Disse to muligheder er temmelig ens, bortset fra at verificere en har ekstra muligheder for den nye værtsinformation. Hvis du følger gendannelsesguiden, skal du angive en ny vært. Hvis "Installer databasesoftware" er aktiveret, vil ClusterControl fjerne enhver eksisterende MySQL-installation på målværten og geninstallere databasesoftwaren med samme version som den eksisterende MySQL-server.
Når sikkerhedskopien er gendannet og verificeret, vil du modtage en meddelelse om gendannelsesstatus, og noden lukkes automatisk ned.
Punkt-i-tidsgendannelse
For MySQL kan både xtrabackup og mysqldump bruges til at udføre punkt-i-tidsgendannelse og også til at klargøre en ny replikeringsslave til master-slave replikering eller Galera Cluster. En mysqldump PITR-kompatibel backup indeholder én enkelt dumpfil med GTID-info, binlog-fil og position. Således vil kun databasenoden, der producerer binær log, have muligheden "PITR-kompatibel" tilgængelig:
Når PITR-kompatibel valgmulighed slås til/fra, er database- og tabelfelterne nedtonede, da ClusterControl altid vil udføre en fuld backup mod alle databaser, hændelser, triggere og rutiner på mål-MySQL-serveren.
Gendanner nu sikkerhedskopien. Hvis sikkerhedskopien er kompatibel med PITR, vil der blive vist en mulighed for at udføre en punkt-i-tidsgendannelse. Du vil have to muligheder for det - "Tidsbaseret" og "Positionsbaseret". For "Tidsbaseret" kan du bare passere dagen og tiden. For "Positionsbaseret" kan du videregive den nøjagtige position til det sted, hvor du vil gendanne. Det er en mere præcis måde at gendanne på, selvom du måske har brug for at få binlog-positionen ved hjælp af mysqlbinlog-værktøjet. Flere detaljer om tidspunkt for gendannelse kan findes i denne blog.
Sikkerhedskopikryptering
Universalt understøtter ClusterControl backup-kryptering til MySQL, MongoDB og PostgreSQL. Sikkerhedskopier krypteres i hvile ved hjælp af AES-256 CBC-algoritme. En automatisk genereret nøgle vil blive gemt i klyngens konfigurationsfil under /etc/cmon.d/cmon_X.cnf (hvor X er klynge-id'et):
$ sudo grep backup_encryption_key /etc/cmon.d/cmon_1.cnf
backup_encryption_key='JevKc23MUIsiWLf2gJWq/IQ1BssGSM9wdVLb+gRGUv0='Hvis sikkerhedskopieringsdestinationen ikke er lokal, overføres sikkerhedskopieringsfilerne i krypteret format. Denne funktion supplerer offsite backup på skyen, hvor vi ikke har fuld adgang til det underliggende lagersystem.
Sidste tanker
Vi viste dig, hvordan du får sikkerhedskopieret dine data, og hvordan du opbevarer dem sikkert uden for stedet. Restitution er altid en anden ting. ClusterControl kan automatisk gendanne dine databaser fra tidligere sikkerhedskopier, som er gemt på stedet eller kopieret tilbage fra skyen.
Der er naturligvis mere til at sikre dine data, især på siden af at sikre dine forbindelser. Vi vil dække dette i det næste blogindlæg!