Säkerhetskopiering är en mycket viktig del av din databasverksamhet, eftersom ditt företag måste säkras när katastrofen inträffar. När den tiden kommer (och det kommer), bör ditt återhämtningspunktsmål (RPO) och återhämtningstidsmål (RTO) vara fördefinierade, eftersom det är så snabbt du kan återhämta dig från incidenten som inträffade.
De flesta organisationer varierar sitt tillvägagångssätt för säkerhetskopiering och försöker ha en kombination av säkerhetskopiering av serverbilder (ögonblicksbilder), logiska och fysiska säkerhetskopior. Dessa säkerhetskopior lagras sedan på flera platser för att undvika lokala eller regionala katastrofer. Det innebär också att data kan återställas på kortast möjliga tid, vilket undviker stora stillestånd som kan påverka ditt företags verksamhet.
Att vara värd för din databas hos en molnleverantör, som Microsoft Azure (som vi kommer att diskutera i den här bloggen), är inget undantag, du måste fortfarande förbereda och definiera din katastrofåterställningspolicy.
Liksom andra offentliga molnerbjudanden erbjuder Microsoft Azure (Azure) ett tillvägagångssätt för säkerhetskopiering som är praktiskt, kostnadseffektivt och utformat för att ge dig återställningsalternativ. Microsoft Azure backup-lösningar låter dig konfigurera och använda och hanteras enkelt med deras Azure Backup eller genom Restore Services Vault (om du använder din databas med virtuella maskiner).
Om du vill ha en hanterad databas i molnet erbjuder Azure Azure Database för MySQL. Detta bör endast användas om du inte vill driva och hantera MySQL-databasen själv. Den här tjänsten erbjuder en rik lösning för säkerhetskopiering som låter dig skapa en säkerhetskopia av din databasinstans, antingen från en lokal region eller genom en georedundant plats. Detta kan vara användbart för dataåterställning. Du kanske till och med kan återställa en nod från en viss tidsperiod, vilket är användbart för att uppnå punkt-i-tidsåterställning. Detta kan göras med bara ett klick.
I den här bloggen kommer vi att täcka alla dessa scenarier för säkerhetskopiering och återställning med en MySQL-databas i Microsoft Azure-molnet.
Utföra säkerhetskopior på en virtuell maskin på Azure
Tyvärr erbjuder inte Microsoft Azure en MySQL-specifik lösning för säkerhetskopiering (t.ex. MySQL Enterprise Backup, Percona XtraBackup eller MariaDB:s Mariabackup).
När du har skapat din virtuella maskin (med hjälp av portalen), kan du ställa in en process för att säkerhetskopiera din virtuella dator med hjälp av Restore Services-valvet. Detta skyddar dig från eventuella incidenter, katastrofer eller katastrofer och data som lagras är krypterad som standard. Att lägga till kryptering är valfritt och, även om det rekommenderas av Azure, kommer det med ett pris. Du kan ta en titt på deras Azure Backup Pricing-sida för mer information.
För att skapa och ställa in en säkerhetskopia, gå till den vänstra panelen och klicka på Alla resurser → Beräkna → Virtuell maskin. Ställ nu in de parametrar som krävs i textfälten. När du är på den sidan, gå till fliken Management och scrolla ner nedan. Du kommer att kunna se hur du kan ställa in eller skapa säkerhetskopian. Se skärmdumpen nedan:
Ställ sedan in din säkerhetskopieringspolicy baserat på dina säkerhetskopieringskrav. Klicka bara på länken Skapa ny i textfältet Backup policy för att skapa en ny policy. Se nedan:
Du kan konfigurera din säkerhetskopieringspolicy med lagring per vecka, månad och år .
När du har konfigurerat din säkerhetskopia kan du kontrollera att du har en säkerhetskopia aktiverad på just den virtuella maskinen du just har skapat. Se skärmdumpen nedan:
Återställ och återställ din virtuella maskin på Azure
Hur du utformar din återställning i Azure beror på vilken typ av policy och krav som ditt program kräver. Det beror också på om RTO och RPO måste vara låga eller osynliga för användaren vid en incident eller under underhåll. Du kan ställa in din virtuella maskin med en tillgänglighetsuppsättning eller på en annan tillgänglighetszon för att uppnå en högre återställningshastighet.
Du kan också ställa in en katastrofåterställning för din virtuella dator för att replikera dina virtuella maskiner till en annan Azure-region för affärskontinuitet och behov av katastrofåterställning. Men detta kanske inte är en bra idé för din organisation eftersom det kommer med en hög kostnad. Om det finns på plats erbjuder Azure dig ett alternativ att återställa eller skapa en virtuell maskin från den skapade säkerhetskopian.
Till exempel, under skapandet av din virtuella maskin kan du gå till fliken Diskar och sedan gå till Datadiskar. Du kan skapa eller bifoga en befintlig disk där du kan bifoga ögonblicksbilden du har tillgänglig. Se skärmdumpen nedan för vilken du kan välja mellan ögonblicksbild eller lagringsblobb:
Du kan också återställa vid en viss tidpunkt precis som i skärmdumpen nedan:
Återställning i Azure kan göras på olika sätt, men den använder samma resurser som du redan har skapat.
Om du till exempel har skapat en ögonblicksbild eller en diskavbildning lagrad i Azure Storage-blobben, om du skapar en ny virtuell dator, kan du använda den resursen så länge den är kompatibel och tillgänglig att använda. Dessutom kanske du till och med kan göra lite filåterställning, förutom att återställa en virtuell dator precis som i skärmdumpen nedan:
Under filåterställning kan du kanske välja från en specifik återställningspunkt , samt ladda ner ett skript för att bläddra och återställa filer. Detta är mycket användbart när du bara behöver en specifik fil men inte hela systemet eller diskvolymen.
Att återställa från säkerhetskopia på en befintlig virtuell dator tar cirka tre minuter. Det tar dock tolv minuter att återställa från backup för att skapa en ny virtuell dator. Detta kan dock bero på storleken på din virtuella dator och nätverksbandbredden som är tillgänglig i Azure. Det som är bra är att när du återställer kommer den att ge dig information om vad som har slutförts och hur mycket tid som återstår. Se till exempel skärmdumpen nedan:
Säkerhetskopiering för Azure Database for MySQL
Azure Database for MySQL är en fullständigt hanterad databastjänst av Microsoft Azure. Den här tjänsten erbjuder ett mycket flexibelt och bekvämt sätt att ställa in dina säkerhetskopierings- och återställningsfunktioner.
När du har skapat din MySQL-serverinstans kan du sedan ställa in säkerhetskopieringslagring och skapa redundansalternativ för backup; antingen lokalt redundant (lokal region) eller georedundant (på en annan region). Azure ger dig den beräknade kostnaden du skulle debiteras för en månad. Se ett exempel på en skärmdump nedan:
Tänk på att georedundanta säkerhetskopieringsalternativ endast är tillgängliga för allmänna ändamål och minnesoptimerade typer av beräkningsnoder. Det är inte tillgängligt på en Basic Compute-nod, men du kan ha din redundans i den lokala regionen (dvs. inom de tillgängliga tillgänglighetszonerna).
När du har en huvudinställning är det enkelt att skapa en replik genom att gå till Azure Database for MySQL-servrar → Välj din MyQL-instans → Replikering → och klicka på Lägg till replik. Din replik kan användas som källa eller återställningsmål vid behov.
Tänk på att i Azure, när du stoppar replikeringen mellan mastern och en replik, kommer detta att vara för evigt och oåterkalleligt eftersom det gör repliken till en fristående server. En replik som skapats med Microsoft Azure är helst en hanterad instans och du kan stoppa och starta replikeringstrådarna precis som du gör på en vanlig master-slave replikering. Du kan göra en omstart och det är allt. Om du skapade repliken manuellt, antingen genom att återställa från mastern eller en säkerhetskopia, (t.ex. via en punkt-i-tidsåterställning), kommer du att kunna stoppa/starta replikeringstrådarna eller ställa in en slavfördröjning om det behövs.
Återställa din Azure-databas för MySQL från en säkerhetskopia
Återställning är mycket enkel och snabb med Azure Portal. Du kan bara trycka på återställningsknappen med din MySQL-instansnod och bara följa användargränssnittet som visas i skärmdumpen nedan:
Sedan kan du välja en tidsperiod och skapa/skapa en ny instans baserat på denna säkerhetskopia:
När du har noden tillgänglig kommer denna nod inte att vara en replik av mästaren ännu. Du måste ställa in detta manuellt med enkla steg med hjälp av deras lagrade procedurer tillgängliga:
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');var,
master_host:värdnamn för huvudservern
master_user:användarnamn för huvudservern
master_password:lösenord för huvudservern
master_log_file:binärt loggfilnamn från att köra show master status
master_log_pos:binär loggposition från att köra visa masterstatus
master_ssl_ca:CA-certifikatets kontext. Om du inte använder SSL, skicka in en tom sträng.
Att starta MySQL-trådarna är som följer,
CALL mysql.az_replication_start;eller så kan du stoppa replikeringstrådarna enligt följande,
CALL mysql.az_replication_stop;eller så kan du ta bort mastern som,
CALL mysql.az_replication_remove_master;eller hoppa över SQL-trådsfel som,
CALL mysql.az_replication_skip_counter;Som nämnts tidigare, när en replik skapas med Microsoft Azure under funktionen Lägg till replik under en MySQL-instans, är dessa specifika lagrade procedurer inte tillgängliga. Proceduren mysql.az_replication_restart kommer dock att vara tillgänglig eftersom du inte får stoppa eller starta replikeringstrådarna för en hanterad replik av Azure. Så exemplet vi har ovan återställdes från en master som tar hela kopian av mastern men fungerar som en enda nod och behöver en manuell inställning för att vara en replik av en befintlig master.
Dessutom, när du har en manuell replik som du har konfigurerat, kommer du inte att kunna se detta under Azure Database for MySQL-servrar → Välj din MyQL-instans → Replikering eftersom du skapade eller konfigurerade replikeringen manuellt .
Alternativa Cloud and Restore Backup Solutions
Det finns vissa scenarier där du vill ha full åtkomst när du tar en fullständig säkerhetskopia av din MySQL-databas i molnet. För att göra detta kan du skapa ditt eget skript eller använda öppen källkodsteknik. Med dessa kan du styra hur data i din MySQL-databas ska säkerhetskopieras och exakt hur den ska lagras.
Du kan också använda Azure Command Line Interface (CLI) för att skapa din anpassade automatisering. Du kan till exempel skapa en ögonblicksbild med följande kommando med Azure CLI:
az snapshot create -g myResourceGroup -source "$osDiskId" --name osDisk-backupeller skapa din MySQL-serverreplik med följande kommando:
az mysql server replica create --name mydemoreplicaserver --source-server mydemoserver --resource-group myresourcegroupAlternativt kan du också använda ett företagsverktyg som innehåller sätt att ta din säkerhetskopia med återställningsalternativ. Att använda öppen källkodsteknik eller verktyg från tredje part kräver kunskap och färdigheter för att utnyttja och skapa din egen implementering. Här är listan du kan använda:
- ClusterControl - Även om vi kan vara lite partiska, erbjuder ClusterControl möjligheten att hantera fysiska och logiska säkerhetskopior av din MySQL-databas med hjälp av stridstestade, öppen källkodsteknik (PXB, Mariabackup och mydumper). Den stöder MySQL, Percona, MariaDB, Galera-databaser. Du kan enkelt skapa vår säkerhetskopieringspolicy och lagra dina databassäkerhetskopior på vilket moln som helst (AWS, GCP eller Azure) Observera att gratisversionen av ClusterControl inte inkluderar säkerhetskopieringsfunktionerna.
- LVM-ögonblicksbilder - Du kan använda LVM för att ta en ögonblicksbild av din logiska volym. Detta är endast tillämpligt för din virtuella dator eftersom den kräver åtkomst till lagring på blocknivå. Att använda det här verktyget kräver varning eftersom det kan göra att din databasnod inte svarar medan säkerhetskopieringen körs.
- Percona XtraBackup (PXB) – En öppen källkodsteknik från Percona. Med PXB kan du skapa en fysisk säkerhetskopia av din MySQL-databas. Du kan också göra en hot-backup med PXB för InnoDB-lagringsmotor men det rekommenderas att köra detta på en slav eller icke-upptagen MySQL db-server. Detta är endast tillämpligt för din VM-instans eftersom den kräver binär eller filåtkomst till själva databasservern.
- Mariabackup – Samma sak med PXB, det är en öppen källkodsteknik som är splittrad från PXB men underhålls av MariaDB. Specifikt, om din databas använder MariaDB, bör du använda Mariabackup för att undvika inkompatibilitetsproblem med tabellutrymmen.
- mydumper/myloader - Dessa säkerhetskopieringsverktyg skapar logiska säkerhetskopior av din MySQL-databas. Du kan använda detta med din Azure-databas för MySQL även om jag inte har provat hur framgångsrikt det är för din säkerhetskopiering och återställning.
- mysqldump - Det är ett logiskt säkerhetskopieringsverktyg som är mycket användbart när du behöver säkerhetskopiera och dumpa (eller återställa) en specifik tabell eller databas till en annan instans. Detta används ofta av DBA:er men du måste vara uppmärksam på ditt diskutrymme eftersom logiska säkerhetskopior är enorma jämfört med fysiska säkerhetskopior.
- MySQL Enterprise Backup - Den levererar heta, online, icke-blockerande säkerhetskopior på flera plattformar inklusive Linux, Windows, Mac och Solaris. Det är inte ett gratis verktyg för säkerhetskopiering men erbjuder många funktioner.
- rsync – Det är ett snabbt och utomordentligt mångsidigt filkopieringsverktyg. Den kan kopiera lokalt, till/från en annan värd över valfritt fjärrskal, eller till/från en fjärrstyrd rsync-demon. Den erbjuder ett stort antal alternativ som kontrollerar varje aspekt av dess beteende och tillåter mycket flexibel specifikation av uppsättningen filer som ska kopieras. Mestadels i Linux-system installeras rsync som en del av OS-paketet.