sql >> Database teknologi >  >> RDS >> MariaDB

Sådan planlægger du databasesikkerhedskopier med ClusterControl

Databasesikkerhedskopiering er en kritisk del af databasestyring og skal planlægges nøje. Det er ikke nok at planlægge en sikkerhedskopi, backupdata skal også verificeres for konsistens og integritet. Der er andre overvejelser som kryptering og arkivering off-site. En god backup manager ville have funktioner, der tager højde for alle disse forskellige overvejelser.

I dette blogindlæg skal vi se på, hvordan du kan planlægge dine databasesikkerhedskopier med ClusterControl.

Database-sikkerhedskopier ved hjælp af ClusterControl

ClusterControl understøtter en række sikkerhedskopieringsmetoder afhængigt af klyngetypen, som opsummeret i følgende tabel:

Klyngetype Understøttet sikkerhedskopieringsmetode
MySQL (replikering, Galera, NDB-klynge, gruppereplikering)
  • mysqldump
  • Percona Xtrabackup (fuld og trinvis)
  • MariaDB Backup (kun MariaDB)
  • NDB Backup (kun MySQL Cluster)
MongoDB (Replica Set, Sharded Cluster)
  • mongodump
  • mongodb-consistent-backup (beta, Percona Server kun til MongoDB)
PostgreSQL (Streaming Replication)
  • pg_dumpall
  • pg_basebackup

Når du planlægger sikkerhedskopiering med ClusterControl, kan hver af sikkerhedskopieringsmetoderne konfigureres med et sæt muligheder for, hvordan du ønsker, at sikkerhedskopieringen skal udføres. Forskellige database-arbejdsbelastninger og backup-strategier vil kræve understøttelse af forskellige funktioner, for eksempel:

  • Disk IOPS drosling
  • Netværksregulering
  • Backuplåse
  • Kryptering
  • Kompression
  • Opbevaringsperiode
  • Bekræftelse

ClusterControl indstiller automatisk en række sikkerhedskopieringsmuligheder efter bedste praksis fra den pågældende databaseleverandør. For eksempel, hvis måldatabasenoden har aktiveret binær log, vil den tilføje et ekstra flag, --master-data at inkludere de binære log-koordinater (filnavn og position) for den dumpede server. Hvis det er en Galera-node, og sikkerhedskopieringsmetoden er xtrabackup, vil ClusterControl tilføje et ekstra flag, --galera-info som indeholder den lokale nodetilstand på tidspunktet for sikkerhedskopieringen.

Planlægning af en sikkerhedskopi

Før vi planlægger en sikkerhedskopi, skal vi planlægge, hvordan sikkerhedskopieringen skal være. Det ville være nyttigt at besvare følgende eksempelspørgsmål, før du opretter en sikkerhedskopieringsplan:

  • Hvilken backupmetode vil du bruge? Nogle sikkerhedskopieringsmetoder er ikke-blokerende, men meget ressourcekrævende. Forstå afvejningen, så du ikke bliver overrasket over, hvordan processen opfører sig i produktionen.
  • Hvor ofte vil du sikkerhedskopiere dine databaser? At køre en fuld sikkerhedskopiering kan være smertefuldt, hvis sikkerhedskopieringsintervallet er for kort. Du har sandsynligvis brug for en blanding af komplette og trinvise sikkerhedskopier.
  • Hvor hurtigt vil du gendanne dine data? Fysisk sikkerhedskopiering er normalt meget hurtigere end logisk sikkerhedskopiering med hensyn til fuld gendannelsestid. På den anden side er logisk sikkerhedskopiering almindeligvis hurtigere ved delvis gendannelse.
  • Hvor stor er din datastørrelse? I nogle tilfælde er logisk backup ikke et godt valg til store databaser, og binær backup er den eneste vej at gå.
  • Hvor meget ledig plads har du til at gemme din sikkerhedskopi? Sikkerhedskopier har en tendens til at æde meget plads. Beslut om kompression er nødvendig og det kompressionsniveau, du har råd til. Bedre komprimering kræver højere CPU-brug.
  • Hvad hvis backup-serveren er nede under backup-tiden? Skal det failover sikkerhedskopien til en anden tilgængelig vært? Det er normalt ikke en god idé at springe en sikkerhedskopi over på grund af et vedligeholdelsesvindue.
  • Hvordan sikrer man integriteten af ​​den oprettede sikkerhedskopi? Husk, at en sikkerhedskopi ikke er en sikkerhedskopi, hvis den ikke kan gendannes.
  • Har du tillid til backup-lageret? Kryptering kan være en god idé for at beskytte dine data.

Generelt kan vi ved at besvare disse spørgsmål komme med en passende backup-strategi. Listen over spørgsmål kan være længere afhængig af din sikkerhedskopierings- og gendannelsespolitik.

Vi har dækket dette kapitel i detaljer i vores hvidbog, The DevOps Guide to Database Backups for MySQL og MariaDB.


Planlægning af en sikkerhedskopi
 

Med ClusterControl er planlægning ret ligetil. Gå direkte til Backup -> Create Backup -> Planlæg sikkerhedskopiering, og du vil blive præsenteret for følgende dialog:

Afhængigt af klyngetypen kan mulighederne være forskellige, som vist i følgende skærmbilleder for PostgreSQL og MongoDB:

PostgreSQL MongoDB

De fleste af mulighederne er selvforklarende og er dækket i detaljer i brugervejledningen. Når tidsplanen er oprettet, kan du redigere konfigurationssikkerhedskopierne, aktivere/deaktivere sikkerhedskopieringen eller slette tidsplanen under fanen "Planlagte sikkerhedskopier":

Vær opmærksom på, når du planlægger backup med ClusterControl, at alle tider skal planlægges i UTC-tidszonen på ClusterControl-serveren. Årsagen bag dette er at afskære forvirringen af ​​backup-udførelsestiden. Når man arbejder med en klynge, kan databaseserverne være spredt i forskellige tidszoner og forskellige geografiske områder. Brug af én referencetidszone til at administrere dem alle vil sikre, at sikkerhedskopierne altid udføres på det rigtige tidspunkt.

Du kan overvåge forløbet af en backup ved at se på Aktivitet -> Jobs, når tiden er inde. Hvis backup-jobbet mislykkedes, ville du se fejlen med det samme:

Ovenstående log er også tilgængelig under fanen Sikkerhedskopiering på hver af backup-posterne:

Kontrol og bekræftelse efter sikkerhedskopiering

Når først backup-jobbet er afsluttet, betyder det ikke, at dit ansvar er forbi. Der er et par ting, der skal følges op på. Den vigtigste er tilstanden af ​​den oprettede sikkerhedskopi. ClusterControl giver e-mail-meddelelser og giver dig besked om status. Denne underretningstjeneste kan naturligvis konfigureres baseret på sværhedsgraden under Indstillinger -> Generelle indstillinger -> Indstillinger for e-mail-meddelelser -> Sikkerhedskopiering:

Levering betyder, at ClusterControl sender en e-mail-meddelelse umiddelbart efter, at en alarm for denne komponent er udløst. Du kan også konfigurere det som Ignorer eller Digest, hvor ClusterControl sender en daglig oversigt over alarmer, der er rejst.

Hvis sikkerhedskopien er oprettet, anbefales det stærkt at kontrollere, om sikkerhedskopien kan gendannes. Du kan bruge funktionen Backup Verification ved at klikke på knappen "Gendan" for det valgte backup-id, og du vil blive præsenteret for to gendannelsesmuligheder:

"Gendan og bekræft på selvstændig vært" kræver en separat vært, som ikke allerede er en del af databaseopsætningen. ClusterControl vil først implementere en MySQL-instans på målværten, starte tjenesten, kopiere sikkerhedskopien fra backup-lageret og starte gendannelsen. Når det er gjort, kan du have mulighed for enten at lukke serveren, når den er gendannet, eller lade den køre, så du kan foretage yderligere undersøgelser på serveren.

Rengøring er også vigtigt for kun at beholde de nyttige sikkerhedskopier i dit lager. Konfigurer derfor backup-retentionen efter behov. Som standard sletter ClusterControl sikkerhedskopier, der er ældre end 30 dage. Du kan også tilpasse hver af backup-planerne med forskellige opbevaringsperioder.

Hvis backup-lageret nærmer sig nogen pladsgrænser, eller du vil arkivere din backup offside, kan du vælge at slette filen manuelt ved at klikke på skraldespand-ikonet eller uploade den til skyen, som fremhævet nedenfor:

I skrivende stund understøttes AWS S3 og GCP Cloud Storage. Cloud-legitimationsoplysningerne skal være forudkonfigureret under Sidemenu -> Integrationer -> Cloud-udbydere.

Det var det, folkens. Glædelig klyngedannelse!


  1. Kører Vitess og MySQL med ClusterControl

  2. Hvorfor bruge INCLUDE-sætningen, når du opretter et indeks?

  3. Oracle til PostgreSQL — Markører og almindelige tabeludtryk

  4. Dataanalyseguide:Det er tid til at udmærke sig ved at bruge Excel!