Back-ups zijn een zeer belangrijk onderdeel van uw databasebewerkingen, aangezien uw bedrijf moet worden beveiligd wanneer zich een ramp voordoet. Wanneer die tijd komt (en dat zal gebeuren), moeten uw Recovery Point Objective (RPO) en Recovery Time Objective (RTO) vooraf worden gedefinieerd, omdat dit is hoe snel u kunt herstellen van het incident dat zich heeft voorgedaan.
De meeste organisaties verschillen in hun benadering van back-ups en proberen een combinatie te maken van back-ups van serverimages (snapshots), logische en fysieke back-ups. Deze back-ups worden vervolgens op meerdere locaties opgeslagen om lokale of regionale calamiteiten te voorkomen. Het betekent ook dat de gegevens in de kortst mogelijke tijd kunnen worden hersteld, waardoor grote uitvaltijd wordt vermeden die van invloed kan zijn op de activiteiten van uw bedrijf.
Het hosten van je database bij een cloudprovider, zoals Microsoft Azure (die we in deze blog zullen bespreken), is geen uitzondering, je moet nog steeds je noodherstelbeleid voorbereiden en definiëren.
Net als andere openbare cloudaanbiedingen biedt Microsoft Azure (Azure) een aanpak voor back-ups die praktisch en kosteneffectief is en ontworpen om u herstelopties te bieden. Met Microsoft Azure-back-upoplossingen kunt u ze configureren en bedienen en ze kunnen eenvoudig worden afgehandeld met behulp van hun Azure Backup of via de Restore Services Vault (als u uw database gebruikt met virtuele machines).
Als u een beheerde database in de cloud wilt, biedt Azure Azure Database for MySQL. Dit mag alleen worden gebruikt als u de MySQL-database niet zelf wilt bedienen en beheren. Deze service biedt een uitgebreide oplossing voor back-up waarmee u een back-up van uw database-instantie kunt maken, hetzij vanuit een lokale regio of via een geo-redundante locatie. Dit kan handig zijn voor gegevensherstel. Mogelijk kunt u zelfs een knooppunt uit een bepaalde periode herstellen, wat handig is voor het bereiken van herstel op een bepaald tijdstip. Dit kan met slechts één klik worden gedaan.
In deze blog behandelen we al deze back-up- en herstelscenario's met behulp van een MySQL-database in de Microsoft Azure-cloud.
Back-ups uitvoeren op een virtuele machine op Azure
Helaas biedt Microsoft Azure geen MySQL-specifieke back-upoplossing (bijv. MySQL Enterprise Backup, Percona XtraBackup of MariaDB's Mariabackup).
Bij het maken van uw virtuele machine (met behulp van de portal), kunt u een proces instellen om een back-up van uw VM te maken met behulp van de Restore Services-kluis. Dit beschermt u tegen elk incident, ramp of catastrofe en de opgeslagen gegevens zijn standaard versleuteld. Het toevoegen van versleuteling is optioneel en, hoewel aanbevolen door Azure, hangt er een prijskaartje aan. U kunt een kijkje nemen op hun Azure Backup-prijspagina voor meer details.
Als u een back-up wilt maken en instellen, gaat u naar het linkerdeelvenster en klikt u op Alle bronnen → Compute → Virtual Machine. Stel nu de vereiste parameters in de tekstvelden in. Zodra u op die pagina bent, gaat u naar het tabblad Beheer en scrolt u naar beneden. U kunt zien hoe u de back-up kunt instellen of maken. Zie de onderstaande schermafbeelding:
Stel vervolgens uw back-upbeleid in op basis van uw back-upvereisten. Klik gewoon op de koppeling Nieuw maken in het tekstveld Back-upbeleid om een nieuw beleid te maken. Zie hieronder:
U kunt uw back-upbeleid configureren met retentie per week, maandelijks en jaarlijks .
Zodra je je back-up hebt geconfigureerd, kun je controleren of je een back-up hebt ingeschakeld op die specifieke virtuele machine die je zojuist hebt gemaakt. Zie de onderstaande schermafbeelding:
Herstel en herstel uw virtuele machine op Azure
Het ontwerpen van uw herstel in Azure hangt af van het soort beleid en de vereisten die uw toepassing vereist. Het hangt er ook van af of RTO en RPO laag of onzichtbaar moeten zijn voor de gebruiker bij een incident of tijdens onderhoud. U kunt uw virtuele machine instellen met een beschikbaarheidsset of op een andere beschikbaarheidszone om een hoger herstelpercentage te bereiken.
U kunt ook een noodherstel instellen voor uw VM om uw virtuele machines naar een andere Azure-regio te repliceren voor bedrijfscontinuïteit en noodherstel. Dit is echter misschien geen goed idee voor uw organisatie, omdat het hoge kosten met zich meebrengt. Indien aanwezig, biedt Azure u een optie om een virtuele machine te herstellen of te maken op basis van de gemaakte back-up.
Tijdens het maken van uw virtuele machine kunt u bijvoorbeeld naar het tabblad Schijven gaan en vervolgens naar Gegevensschijven. U kunt een bestaande schijf maken of koppelen waar u de beschikbare momentopname kunt toevoegen. Zie de onderstaande schermafbeelding waarvoor u kunt kiezen uit snapshot of opslagblob:
Je kunt ook herstellen op een specifiek tijdstip, net zoals in de schermafbeelding hieronder:
Herstellen in Azure kan op verschillende manieren, maar het gebruikt dezelfde bronnen die u al hebt gemaakt.
Als u bijvoorbeeld een momentopname of een schijfkopie hebt gemaakt die is opgeslagen in de Azure Storage-blob en u een nieuwe VM maakt, kunt u die resource gebruiken zolang deze compatibel en beschikbaar is voor gebruik. Bovendien kun je misschien zelfs wat bestandsherstel doen, afgezien van het herstellen van een VM, zoals in de onderstaande schermafbeelding:
Tijdens Bestandsherstel kunt u mogelijk kiezen uit een specifiek herstelpunt , evenals een script downloaden om door bestanden te bladeren en bestanden te herstellen. Dit is erg handig als je alleen een specifiek bestand nodig hebt, maar niet het hele systeem of schijfvolume.
Herstellen vanaf een back-up op een bestaande VM duurt ongeveer drie minuten. Het herstellen van een back-up om een nieuwe VM te spawnen duurt echter twaalf minuten. Dit kan echter afhangen van de grootte van uw virtuele machine en de netwerkbandbreedte die beschikbaar is in Azure. Het goede ding is dat het u bij het herstellen details geeft over wat er is voltooid en hoeveel tijd er nog is. Zie bijvoorbeeld de onderstaande schermafbeelding:
Back-ups voor Azure Database For MySQL
Azure Database for MySQL is een volledig beheerde databaseservice van Microsoft Azure. Deze service biedt een zeer flexibele en gemakkelijke manier om uw back-up- en herstelmogelijkheden in te stellen.
Na het maken van uw MySQL-serverinstantie, kunt u back-upretentie instellen en uw back-upredundantie-opties maken; ofwel lokaal redundant (lokale regio) of geo-redundant (in een andere regio). Azure geeft u de geschatte kosten die voor een maand in rekening worden gebracht. Bekijk hieronder een voorbeeldscreenshot:
Houd er rekening mee dat geo-redundante back-upopties alleen beschikbaar zijn voor algemeen gebruik en voor geheugen geoptimaliseerde typen rekenknooppunten. Het is niet beschikbaar op een Basic-rekenknooppunt, maar u kunt uw redundantie in de lokale regio hebben (d.w.z. binnen de beschikbare beschikbaarheidszones).
Zodra u een hoofdconfiguratie hebt, kunt u eenvoudig een replica maken door naar Azure Database for MySQL-servers te gaan → Selecteer uw MyQL-instantie → Replicatie → en klik op Replica toevoegen. Uw replica kan indien nodig worden gebruikt als bron of hersteldoel.
Houd er rekening mee dat wanneer u in Azure de replicatie tussen de master en een replica stopt, dit voor altijd en onomkeerbaar is, omdat de replica hierdoor een zelfstandige server wordt. Een replica die is gemaakt met Microsoft Azure is idealiter een beheerd exemplaar en u kunt de replicatiethreads stoppen en starten, net als bij een normale master-slave-replicatie. U kunt opnieuw opstarten en dat is alles. Als u de replica handmatig hebt gemaakt, door ofwel te herstellen vanaf de master of een back-up, (bijvoorbeeld via een herstel op een bepaald tijdstip), dan kunt u de replicatiethreads stoppen/starten of indien nodig een slaafvertraging instellen.
Uw Azure-database herstellen voor MySQL vanaf een back-up
Herstellen gaat heel eenvoudig en snel met behulp van de Azure-portal. U kunt gewoon op de herstelknop drukken met uw MySQL-instantieknooppunt en gewoon de gebruikersinterface volgen zoals weergegeven in de onderstaande schermafbeelding:
Vervolgens kunt u een tijdsperiode selecteren en een nieuwe instantie maken/spawnen op basis van deze gemaakte back-up:
Zodra u het knooppunt beschikbaar heeft, is dit knooppunt geen replica van de meester nog niet. U moet dit handmatig instellen met eenvoudige stappen met behulp van hun opgeslagen procedures die beschikbaar zijn:
CALL mysql.az_replication_change_master('<master_host>', '<master_user>', '<master_password>', 3306, '<master_log_file>', <master_log_pos>, '<master_ssl_ca>');waar,
master_host:hostnaam van de masterserver
master_user:gebruikersnaam voor de masterserver
master_password:wachtwoord voor de masterserver
master_log_file:binaire logbestandsnaam vanaf het uitvoeren van show masterstatus
master_log_pos:binaire logpositie van draaiende showmasterstatus
master_ssl_ca:de context van het CA-certificaat. Als u geen SSL gebruikt, geef dan een lege tekenreeks door.
Het starten van de MySQL-threads gaat als volgt,
CALL mysql.az_replication_start;of u kunt de replicatiethreads als volgt stoppen,
CALL mysql.az_replication_stop;of u kunt de master verwijderen als,
CALL mysql.az_replication_remove_master;of sla SQL-threadfouten over als,
CALL mysql.az_replication_skip_counter;Zoals eerder vermeld, zijn deze specifieke opgeslagen procedures niet beschikbaar wanneer een replica wordt gemaakt met Microsoft Azure onder de functie Replica toevoegen onder een MySQL-instantie. De procedure mysql.az_replication_restart is echter wel beschikbaar omdat u de replicatiethreads van een beheerde replica door Azure niet mag stoppen of starten. Dus het voorbeeld dat we hierboven hebben is hersteld van een master die de volledige kopie van de master neemt, maar fungeert als een enkel knooppunt en een handmatige configuratie nodig heeft om een replica van een bestaande master te zijn.
Als u bovendien een handmatige replica hebt ingesteld, kunt u deze niet zien onder Azure Database for MySQL-servers → Selecteer uw MyQL-instantie → Replicatie omdat u de replicatie handmatig hebt gemaakt of ingesteld .
Alternatieve cloud- en herstelback-upoplossingen
Er zijn bepaalde scenario's waarin u volledige toegang wilt hebben bij het maken van een volledige back-up van uw MySQL-database in de cloud. Om dit te doen, kunt u uw eigen script maken of open source-technologieën gebruiken. Hiermee kunt u bepalen hoe de gegevens in uw MySQL-database moeten worden geback-upt en hoe deze precies moeten worden opgeslagen.
U kunt ook gebruikmaken van Azure Command Line Interface (CLI) om uw aangepaste automatisering te maken. U kunt bijvoorbeeld een momentopname maken met behulp van de volgende opdracht met Azure CLI:
az snapshot create -g myResourceGroup -source "$osDiskId" --name osDisk-backupof maak uw MySQL-serverreplica met de volgende opdracht:
az mysql server replica create --name mydemoreplicaserver --source-server mydemoserver --resource-group myresourcegroupAls alternatief kunt u ook gebruikmaken van een bedrijfstool met manieren om uw back-up te maken met herstelopties. Het gebruik van open-sourcetechnologieën of tools van derden vereist kennis en vaardigheden om uw eigen implementatie te benutten en te creëren. Dit is de lijst die u kunt gebruiken:
- ClusterControl - Hoewel we misschien een beetje bevooroordeeld zijn, biedt ClusterControl de mogelijkheid om fysieke en logische back-ups van uw MySQL-database te beheren met behulp van beproefde, open-source technologieën (PXB, Mariabackup en mydumper). Het ondersteunt MySQL, Percona, MariaDB, Galera-databases. U kunt eenvoudig ons back-upbeleid maken en uw databaseback-ups opslaan in elke cloud (AWS, GCP of Azure). Houd er rekening mee dat de gratis versie van ClusterControl de back-upfuncties niet bevat.
- LVM-snapshots - U kunt LVM gebruiken om een momentopname te maken van uw logische volume. Dit is alleen van toepassing op uw virtuele machine, omdat deze toegang tot opslag op blokniveau vereist. Het gebruik van deze tool vereist een waarschuwing, aangezien het uw databaseknooppunt niet meer kan reageren terwijl de back-up wordt uitgevoerd.
- Percona XtraBackup (PXB) - Een open source technologie van Percona. Met PXB kunt u een fysieke reservekopie van uw MySQL-database maken. U kunt ook een hot-back-up maken met PXB voor InnoDB-opslagengine, maar het wordt aanbevolen om dit op een slave of niet-bezette MySQL db-server uit te voeren. Dit is alleen van toepassing op uw VM-instantie, omdat hiervoor binaire of bestandstoegang tot de databaseserver zelf nodig is.
- Mariaback-up - Hetzelfde met PXB, het is een open-source technologie die is afgeleid van PXB maar wordt onderhouden door MariaDB. In het bijzonder, als uw database MariaDB gebruikt, moet u Mariabackup gebruiken om incompatibiliteitsproblemen met tabelruimten te voorkomen.
- mijndumper/mijnlader - Deze back-uptools maken een logische back-up van uw MySQL-database. U kunt dit gebruiken met uw Azure-database voor MySQL, hoewel ik niet heb geprobeerd hoe succesvol dit is voor uw back-up- en herstelprocedure.
- mysqldump - het is een logische back-uptool die erg handig is wanneer u een back-up moet maken en een specifieke tabel of database moet dumpen (of herstellen) naar een andere instantie. Dit wordt vaak gebruikt door DBA's, maar u moet op uw schijfruimte letten, aangezien logische back-ups enorm zijn in vergelijking met fysieke back-ups.
- MySQL Enterprise-back-up - Het levert hot, online, niet-blokkerende back-ups op meerdere platforms, waaronder Linux, Windows, Mac &Solaris. Het is geen gratis back-uptool, maar biedt veel functies.
- rsync - Het is een snelle en buitengewoon veelzijdige tool voor het kopiëren van bestanden. Het kan lokaal kopiëren van/naar een andere host via elke externe shell, of van/naar een externe rsync-daemon. Het biedt een groot aantal opties die elk aspect van zijn gedrag beheersen en een zeer flexibele specificatie van de set bestanden die moeten worden gekopieerd, mogelijk maken. Meestal wordt rsync op Linux-systemen geïnstalleerd als onderdeel van het besturingssysteempakket.