Sikkerhedskopier er en meget vigtig del af din databasedrift, da din virksomhed skal være sikret, når katastrofen rammer. Når den tid kommer (og det vil det), bør dit Recovery Point Objective (RPO) og Recovery Time Objective (RTO) være foruddefineret, da det er hvor hurtigt du kan komme dig over hændelsen, der opstod.
De fleste organisationer varierer deres tilgang til sikkerhedskopiering og forsøger at have en kombination af backup af serverbilleder (snapshots), logiske og fysiske sikkerhedskopier. Disse sikkerhedskopier gemmes derefter flere steder for at undgå lokale eller regionale katastrofer. Det betyder også, at dataene kan gendannes på kortest tid, så man undgår større nedetid, som kan påvirke din virksomheds forretning.
At hoste din database hos en cloud-udbyder, såsom Microsoft Azure (som vi vil diskutere i denne blog), er ikke en undtagelse, du skal stadig forberede og definere din katastrofegendannelsespolitik.
Ligesom andre offentlige cloud-tilbud tilbyder Microsoft Azure (Azure) en tilgang til sikkerhedskopiering, der er praktisk, omkostningseffektiv og designet til at give dig gendannelsesmuligheder. Microsoft Azure backup-løsninger giver dig mulighed for at konfigurere og betjene og håndteres nemt ved hjælp af deres Azure Backup eller gennem Restore Services Vault (hvis du betjener din database ved hjælp af virtuelle maskiner).
Hvis du vil have en administreret database i skyen, tilbyder Azure Azure Database til MySQL. Dette bør kun bruges, hvis du ikke selv ønsker at betjene og administrere MySQL-databasen. Denne service tilbyder en rig løsning til backup, som giver dig mulighed for at oprette en backup af din databaseinstans, enten fra en lokal region eller gennem en geo-redundant placering. Dette kan være nyttigt til datagendannelse. Du kan endda være i stand til at gendanne en node fra en bestemt tidsperiode, hvilket er nyttigt til at opnå punkt-i-tidsgendannelse. Dette kan gøres med et enkelt klik.
I denne blog vil vi dække alle disse sikkerhedskopierings- og gendannelsesscenarier ved hjælp af en MySQL-database på Microsoft Azure-skyen.
Udførelse af sikkerhedskopier på en virtuel maskine på Azure
Desværre tilbyder Microsoft Azure ikke en MySQL-specifik backup-løsning (f.eks. MySQL Enterprise Backup, Percona XtraBackup eller MariaDB's Mariabackup).
Når du har oprettet din virtuelle maskine (ved hjælp af portalen), kan du konfigurere en proces til at sikkerhedskopiere din VM ved hjælp af Restore Services-boksen. Dette vil beskytte dig mod enhver hændelse, katastrofe eller katastrofe, og de lagrede data er krypteret som standard. Tilføjelse af kryptering er valgfrit, og selvom det anbefales af Azure, kommer det med en pris. Du kan tage et kig på deres Azure Backup Pricing-side for flere detaljer.
For at oprette og konfigurere en sikkerhedskopi skal du gå til venstre panel og klikke på Alle ressourcer → Beregn → Virtuel maskine. Indstil nu de nødvendige parametre i tekstfelterne. Når du er på den side, skal du gå til fanen Administration og rulle ned nedenfor. Du vil være i stand til at se, hvordan du kan konfigurere eller oprette sikkerhedskopien. Se skærmbilledet nedenfor:
Sæt derefter din sikkerhedskopieringspolitik baseret på dine sikkerhedskopieringskrav. Bare tryk på linket Opret ny i tekstfeltet Backup-politik for at oprette en ny politik. Se nedenfor:
Du kan konfigurere din sikkerhedskopieringspolitik med opbevaring efter uge, månedlig og årlig .
Når du har konfigureret din sikkerhedskopi, kan du kontrollere, at du har en sikkerhedskopi aktiveret på netop den virtuelle maskine, du lige har oprettet. Se skærmbilledet nedenfor:
Gendan og gendan din virtuelle maskine på Azure
Design af din gendannelse i Azure afhænger af, hvilken type politik og krav din applikation kræver. Det afhænger også af, om RTO og RPO skal være lav eller usynlig for brugeren i tilfælde af en hændelse eller under vedligeholdelse. Du kan konfigurere din virtuelle maskine med et tilgængelighedssæt eller på en anden tilgængelighedszone for at opnå en højere gendannelseshastighed.
Du kan også konfigurere en katastrofegendannelse til din VM for at replikere dine virtuelle maskiner til en anden Azure-region for at få behov for forretningskontinuitet og katastrofegendannelse. Dette er dog muligvis ikke en god idé for din organisation, da det er forbundet med høje omkostninger. Hvis det er på plads, tilbyder Azure dig en mulighed for at gendanne eller oprette en virtuel maskine fra den oprettede sikkerhedskopi.
For eksempel, under oprettelsen af din virtuelle maskine, kan du gå til fanen Diske og derefter gå til Datadiske. Du kan oprette eller vedhæfte en eksisterende disk, hvor du kan vedhæfte det snapshot, du har til rådighed. Se skærmbilledet nedenfor, som du vil være i stand til at vælge mellem snapshot eller storage blob til:
Du kan også gendanne på et bestemt tidspunkt ligesom på skærmbilledet nedenfor:
Gendannelse i Azure kan udføres på forskellige måder, men den bruger det samme ressourcer, du allerede har oprettet.
Hvis du f.eks. har oprettet et snapshot eller et diskbillede, der er gemt i Azure Storage-blobben, kan du, hvis du opretter en ny VM, bruge den ressource, så længe den er kompatibel og tilgængelig til brug. Derudover kan du endda være i stand til at lave noget filgendannelse, bortset fra at gendanne en VM ligesom i skærmbilledet nedenfor:
Under filgendannelse kan du muligvis vælge fra et specifikt gendannelsespunkt , samt downloade et script til at gennemse og gendanne filer. Dette er meget nyttigt, når du kun har brug for en bestemt fil, men ikke hele systemet eller diskvolumen.
Gendannelse fra backup på en eksisterende VM tager omkring tre minutter. Det tager dog tolv minutter at gendanne fra backup for at skabe en ny VM. Dette kan dog afhænge af størrelsen på din VM og den tilgængelige netværksbåndbredde i Azure. Den gode ting er, at den, når den gendannes, vil give dig detaljer om, hvad der er blevet gennemført, og hvor meget tid der er tilbage. Se f.eks. skærmbilledet nedenfor:
Sikkerhedskopier til Azure-database til MySQL
Azure Database til MySQL er en fuldt administreret databasetjeneste af Microsoft Azure. Denne service tilbyder en meget fleksibel og praktisk måde at konfigurere dine sikkerhedskopierings- og gendannelsesfunktioner på.
Når du har oprettet din MySQL-serverforekomst, kan du derefter konfigurere backup-retention og oprette dine backup-redundansmuligheder; enten lokalt redundant (lokal region) eller geo-redundant (på en anden region). Azure giver dig de anslåede omkostninger, du ville blive opkrævet for en måned. Se et eksempel på et skærmbillede nedenfor:
Husk på, at geo-redundante sikkerhedskopieringsmuligheder kun er tilgængelige for generelle formål og hukommelsesoptimerede typer computerknudepunkter. Det er ikke tilgængeligt på en Basic compute node, men du kan have din redundans i den lokale region (dvs. inden for de tilgængelige tilgængelighedszoner).
Når du har en masteropsætning, er det nemt at oprette en replika ved at gå til Azure Database for MySQL-servere → Vælg din MyQL-instans → Replikering → og klik på Tilføj replika. Din replika kan bruges som kilde eller gendannelsesmål, når det er nødvendigt.
Husk på, at når du stopper replikationen mellem masteren og en replika i Azure, vil dette være evigt og irreversibelt, da det gør replikaen til en selvstændig server. En replika, der er oprettet ved hjælp af Microsoft Azure, er ideelt set en administreret forekomst, og du kan stoppe og starte replikeringstrådene, ligesom du gør på en normal master-slave-replikering. Du kan genstarte, og det er alt. Hvis du har oprettet replikaen manuelt, enten ved at gendanne fra masteren eller en sikkerhedskopi (f.eks. via en punkt-i-tidsgendannelse), så vil du være i stand til at stoppe/starte replikeringstrådene eller opsætte en slaveforsinkelse, hvis det er nødvendigt.
Gendannelse af din Azure-database til MySQL fra en sikkerhedskopi
Gendannelse er meget let og hurtig ved at bruge Azure-portalen. Du kan bare trykke på gendannelsesknappen med din MySQL-instansknude og bare følge brugergrænsefladen som vist på skærmbilledet nedenfor:
Så kan du vælge en tidsperiode og oprette/afføde en ny instans baseret på denne taget backup:
Når du har noden tilgængelig, vil denne node ikke være en replika af mesteren endnu. Du skal manuelt konfigurere dette med nemme trin ved hjælp af deres tilgængelige lagrede procedurer:
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');hvor,
master_host:værtsnavn på masterserveren
master_user:brugernavn til masterserveren
master_password:adgangskode til masterserveren
master_log_file:binært logfilnavn fra at køre show master status
master_log_pos:binær logposition fra at køre vis masterstatus
master_ssl_ca:CA-certifikatets kontekst. Hvis du ikke bruger SSL, skal du sende en tom streng.
Derefter starter MySQL-trådene som følger,
CALL mysql.az_replication_start;eller du kan stoppe replikeringstrådene som følger,
CALL mysql.az_replication_stop;eller du kan fjerne masteren som,
CALL mysql.az_replication_remove_master;eller spring SQL-trådfejl over som,
CALL mysql.az_replication_skip_counter;Som tidligere nævnt, når en replika oprettes ved hjælp af Microsoft Azure under Tilføj replika-funktionen under en MySQL-instans, er disse specifikke lagrede procedurer ikke tilgængelige. Mysql.az_replication_restart-proceduren vil dog være tilgængelig, da du ikke har tilladelse til at stoppe eller starte replikeringstrådene for en administreret replika af Azure. Så eksemplet, vi har ovenfor, blev gendannet fra en master, som tager den fulde kopi af masteren, men fungerer som en enkelt node og har brug for en manuel opsætning for at være en kopi af en eksisterende master.
Derudover, når du har en manuel replika, som du har opsat, vil du ikke kunne se dette under Azure Database for MySQL-servere → Vælg din MyQL-instans → Replikering, da du har oprettet eller opsat replikeringen manuelt .
Alternative Cloud and Restore Backup Solutions
Der er visse scenarier, hvor du vil have fuld adgang, når du tager en fuld backup af din MySQL-database i skyen. For at gøre dette kan du oprette dit eget script eller bruge open source-teknologier. Med disse kan du styre, hvordan dataene i din MySQL-database skal sikkerhedskopieres, og præcist hvordan de skal opbevares.
Du kan også bruge Azure Command Line Interface (CLI) til at skabe din tilpassede automatisering. For eksempel kan du oprette et snapshot ved hjælp af følgende kommando med Azure CLI:
az snapshot create -g myResourceGroup -source "$osDiskId" --name osDisk-backupeller opret din MySQL-serverreplika med følgende kommando:
az mysql server replica create --name mydemoreplicaserver --source-server mydemoserver --resource-group myresourcegroupAlternativt kan du også bruge et virksomhedsværktøj, der indeholder måder at tage din backup på med gendannelsesmuligheder. Brug af open source-teknologier eller 3. parts værktøjer kræver viden og færdigheder for at udnytte og skabe din egen implementering. Her er listen, du kan bruge:
- Klyngekontrol - Selvom vi måske er lidt forudindtaget, tilbyder ClusterControl muligheden for at administrere fysiske og logiske sikkerhedskopier af din MySQL-database ved hjælp af kamptestede open source-teknologier (PXB, Mariabackup og mydumper). Det understøtter MySQL, Percona, MariaDB, Galera-databaser. Du kan nemt oprette vores sikkerhedskopieringspolitik og gemme dine databasesikkerhedskopier på enhver sky (AWS, GCP eller Azure). Bemærk venligst, at den gratis version af ClusterControl ikke inkluderer sikkerhedskopieringsfunktionerne.
- LVM Snapshots - Du kan bruge LVM til at tage et øjebliksbillede af din logiske volumen. Dette gælder kun for din VM, da det kræver adgang til lager på blokniveau. Brug af dette værktøj kræver advarsel, da det kan få din databaseknude til at reagere, mens sikkerhedskopien kører.
- Percona XtraBackup (PXB) - En open source-teknologi fra Percona. Med PXB kan du oprette en fysisk sikkerhedskopi af din MySQL-database. Du kan også lave en hot-backup med PXB til InnoDB-lagringsmotor, men det anbefales at køre dette på en slave eller ikke-optaget MySQL db-server. Dette gælder kun for din VM-instans, da den kræver binær eller filadgang til selve databaseserveren.
- Mariabackup - Det samme med PXB, det er en open source-teknologi fordelt fra PXB, men vedligeholdes af MariaDB. Specifikt, hvis din database bruger MariaDB, bør du bruge Mariabackup for at undgå inkompatibilitetsproblemer med tablespaces.
- mydumper/myloader - Disse sikkerhedskopieringsværktøjer opretter logiske sikkerhedskopier af din MySQL-database. Du kan bruge dette med din Azure-database til MySQL, selvom jeg ikke har prøvet, hvor vellykket dette er til din sikkerhedskopierings- og gendannelsesprocedure.
- mysqldump - det er et logisk backupværktøj, som er meget nyttigt, når du skal sikkerhedskopiere og dumpe (eller gendanne) en specifik tabel eller database til en anden instans. Dette er almindeligt brugt af DBA'er, men du skal være opmærksom på din diskplads, da logiske sikkerhedskopier er enorme sammenlignet med fysiske sikkerhedskopier.
- MySQL Enterprise Backup - Det leverer varme, online, ikke-blokerende sikkerhedskopier på flere platforme, herunder Linux, Windows, Mac &Solaris. Det er ikke et gratis sikkerhedskopieringsværktøj, men tilbyder en masse funktioner.
- rsync - Det er et hurtigt og ekstraordinært alsidigt filkopieringsværktøj. Den kan kopiere lokalt, til/fra en anden vært over en hvilken som helst ekstern shell, eller til/fra en ekstern rsync-dæmon. Det tilbyder et stort antal muligheder, der kontrollerer alle aspekter af dets adfærd og tillader meget fleksibel specifikation af det sæt filer, der skal kopieres. For det meste i Linux-systemer er rsync installeret som en del af OS-pakken.