Delen via

Back-up en herstel in Azure Database for MySQL

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - enkele server

Belangrijk

Azure Database for MySQL enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan een upgrade uit te voeren naar een flexibele Azure Database for MySQL-server. Zie Wat gebeurt er met Azure Database for MySQL Enkele server voor meer informatie over migreren naar Azure Database for MySQL Flexibele server ?

In Azure DB for MySQL worden automatisch serverback-ups gemaakt en opgeslagen in een door de gebruiker geconfigureerde lokaal of geografisch redundante opslag. Back-ups kunnen worden gebruikt om de status van de server naar een bepaald tijdstip te herstellen. Back-ups maken en herstellen zijn essentiële onderdelen van een strategie voor bedrijfscontinuïteit omdat ze uw gegevens beschermen tegen onbedoelde beschadiging of verwijdering.

Back-ups

Azure Database for MySQL maakt back-ups van de gegevensbestanden en het transactielogboek. Met deze back-ups kunt u een server herstellen naar een bepaald tijdstip binnen de geconfigureerde bewaarperiode voor back-ups. De standaardretentieperiode voor back-ups is zeven dagen. U kunt deze desgewenst tot 35 dagen configureren. Alle back-ups worden versleuteld met AES 256-bits versleuteling.

Deze back-upbestanden zijn niet beschikbaar voor gebruikers en kunnen niet worden geëxporteerd. Deze back-ups kunnen alleen worden gebruikt voor herstelbewerkingen in Azure Database for MySQL. U kunt mysqldump gebruiken om een database te kopiëren.

Het back-uptype en de frequentie zijn afhankelijk van de back-endopslag voor de servers.

Back-uptype en frequentie

Standaardopslagservers

De Basic-opslag is de back-endopslag die servers in de Basic-laag ondersteunt. Back-ups op Basic-opslagservers zijn gebaseerd op momentopnamen. Er wordt dagelijks een volledige momentopname van de database uitgevoerd. Er zijn geen differentiële back-ups uitgevoerd voor basisopslagservers en alle momentopnameback-ups zijn alleen volledige databaseback-ups.

Back-ups van transactielogboeken worden elke vijf minuten uitgevoerd.

Opslag voor algemeen gebruik v1-servers (ondersteunt maximaal 4 TB-opslag)

De opslag voor algemeen gebruik is de back-endopslag die de server algemeen gebruik en geoptimaliseerd voor geheugen ondersteunt. Voor servers met opslag voor algemeen gebruik tot 4 TB vindt elke week volledige back-ups plaats. Differentiële back-ups vinden twee keer per dag plaats. Back-ups van transactielogboeken worden elke vijf minuten uitgevoerd. De back-ups voor opslag voor algemeen gebruik tot 4 TB opslag zijn niet gebaseerd op momentopnamen en verbruiken IO-bandbreedte op het moment van de back-up. Voor grote databases (> 1 TB) op 4 TB-opslag raden we u aan te overwegen

  • Meer IOPS inrichten voor account voor back-up-IOs OF
  • U kunt ook migreren naar opslag voor algemeen gebruik die ondersteuning biedt voor maximaal 16 TB-opslag als de onderliggende opslaginfrastructuur beschikbaar is in uw Favoriete Azure-regio's. Er zijn geen extra kosten verbonden aan opslag voor algemeen gebruik die ondersteuning biedt voor maximaal 16 TB opslagruimte. Voor hulp bij migratie naar opslag van 16 TB opent u een ondersteuningsticket vanuit De Azure-portal.

Opslag voor algemeen gebruik v2-servers (ondersteunt maximaal 16 TB-opslag)

In een subset van Azure-regio's kunnen alle nieuw ingerichte servers opslag voor algemeen gebruik tot 16 TB-opslag ondersteunen. Met andere woorden, opslag tot 16 TB opslag is de standaardopslag voor algemeen gebruik voor alle regio's waar deze wordt ondersteund. Back-ups op deze opslagservers van 16 TB zijn gebaseerd op momentopnamen. De eerste momentopnameback-up wordt gepland direct nadat een server is gemaakt. Momentopnameback-ups worden eenmaal per dag gemaakt. Back-ups van transactielogboeken worden elke vijf minuten uitgevoerd.

Raadpleeg de opslagdocumentatie voor meer informatie over Basic- en Algemeen gebruik.

Back-upretentie

Back-ups worden bewaard op basis van de instelling voor de bewaarperiode voor back-ups op de server. U kunt een bewaarperiode van 7 tot 35 dagen selecteren. De standaardretentieperiode is 7 dagen. U kunt de bewaarperiode instellen tijdens het maken van de server of later door de back-upconfiguratie bij te werken met behulp van Azure Portal of Azure CLI.

De bewaarperiode voor back-ups bepaalt hoe ver terug in de tijd een herstel naar een bepaald tijdstip kan worden opgehaald, omdat deze is gebaseerd op beschikbare back-ups. De bewaarperiode voor back-ups kan ook worden behandeld als een herstelvenster vanuit het perspectief van herstel. Alle back-ups die nodig zijn om een herstel naar een bepaald tijdstip in de bewaarperiode voor back-ups uit te voeren, worden bewaard in de back-upopslag. Als de bewaarperiode voor back-ups bijvoorbeeld is ingesteld op 7 dagen, wordt het herstelvenster beschouwd als afgelopen 7 dagen. In dit scenario worden alle back-ups die nodig zijn om de server in de afgelopen 7 dagen te herstellen, bewaard. Met een bewaarperiode voor back-ups van zeven dagen:

  • Opslag voor algemeen gebruik v1-servers (ondersteuning voor maximaal 4 TB-opslag) behoudt maximaal 2 volledige databaseback-ups, alle differentiële back-ups en back-ups van transactielogboeken die worden uitgevoerd sinds de vroegste volledige databaseback-up.
  • Opslag v2-servers voor algemeen gebruik (die ondersteuning bieden voor maximaal 16 TB-opslag) behoudt de volledige databasemomentopnamen en back-ups van transactielogboeken in de afgelopen 8 dagen.

Langetermijnretentie

Langetermijnretentie van back-ups van meer dan 35 dagen wordt momenteel nog niet door de service ondersteund. U hebt een optie om mysqldump te gebruiken om back-ups te maken en op te slaan voor langetermijnretentie. Ons ondersteuningsteam heeft een stapsgewijs artikel geregistreerd om te delen hoe u dit kunt bereiken.

Redundantieopties voor back-up

Azure Database for MySQL biedt de flexibiliteit om te kiezen tussen lokaal redundante of geografisch redundante back-upopslag in de lagen Algemeen gebruik en Geoptimaliseerd voor geheugen. Wanneer de back-ups worden opgeslagen in geografisch redundante back-upopslag, worden ze niet alleen opgeslagen in de regio waarin uw server wordt gehost, maar worden ze ook gerepliceerd naar een gekoppeld datacenter. Deze georedundantie biedt betere beveiliging en de mogelijkheid om uw server in een andere regio te herstellen in het geval van een noodgeval. De Basic-laag biedt alleen lokaal redundante back-upopslag.

Notitie

Voor de volgende regio's - India - centraal, Frankrijk - centraal, UAE - noord, Zuid-Afrika - noord; Opslag voor algemeen gebruik v2 bevindt zich in openbare preview. Als u een bronserver maakt in Opslag v2 voor algemeen gebruik (ondersteuning voor maximaal 16 TB-opslag) in de bovenstaande regio's, wordt het inschakelen van geografisch redundante back-up niet ondersteund.

Overstappen van lokaal redundante back-upopslag naar geografisch redundante back-upopslag

Het configureren van lokaal redundante of geografisch redundante opslag voor back-up is alleen toegestaan tijdens het maken van een server. Zodra de server is ingericht, kunt u de optie voor redundantie van back-upopslag niet meer wijzigen. Als u uw back-upopslag wilt verplaatsen van lokaal redundante opslag naar geografisch redundante opslag, is het maken van een nieuwe server en het migreren van de gegevens met behulp van dump en herstel de enige ondersteunde optie.

Kosten van back-upopslag

Azure Database for MySQL biedt tot 100% van uw ingerichte serveropslag als back-upopslag, zonder extra kosten. Eventuele extra gebruikte back-upopslag wordt in GB per maand in rekening gebracht. Als u bijvoorbeeld een server hebt ingericht met 250 GB opslagruimte, hebt u 250 GB extra opslagruimte beschikbaar voor serverback-ups zonder extra kosten. Opslag die wordt verbruikt voor back-ups van meer dan 250 GB, wordt in rekening gebracht volgens het prijsmodel.

U kunt de metrische gegevens van Backup Storage gebruiken in Azure Monitor die beschikbaar zijn via Azure Portal om de back-upopslag te bewaken die door een server wordt verbruikt. De metrische gegevens back-upopslag die wordt gebruikt, vertegenwoordigt de som van de opslag die wordt gebruikt door alle volledige databaseback-ups, differentiële back-ups en logboekback-ups die worden bewaard op basis van de bewaarperiode voor back-ups die zijn ingesteld voor de server. De frequentie van de back-ups wordt beheerd door de service en wordt eerder uitgelegd. Intensieve transactionele activiteit op de server kan ertoe leiden dat het gebruik van back-upopslag toeneemt, onafhankelijk van de totale databasegrootte. Voor geografisch redundante opslag is het gebruik van back-upopslag twee keer zo hoog als die van de lokaal redundante opslag.

De belangrijkste manier om de kosten voor back-upopslag te beheren, is door de juiste bewaarperiode voor back-ups in te stellen en de juiste opties voor back-upredundantie te kiezen om te voldoen aan de gewenste hersteldoelen. U kunt een bewaarperiode van 7 tot 35 dagen selecteren. Servers voor algemeen gebruik en geoptimaliseerd voor geheugen kunnen ervoor kiezen om geografisch redundante opslag voor back-ups te hebben.

Herstellen

In Azure Database for MySQL maakt het uitvoeren van een herstelbewerking een nieuwe server op basis van de back-ups van de oorspronkelijke server en worden alle databases in de server hersteld. Herstellen wordt momenteel niet ondersteund als de oorspronkelijke server de status Gestopt heeft.

Er zijn twee soorten herstel beschikbaar:

  • Herstel naar een bepaald tijdstip is beschikbaar met de optie back-upredundantie en maakt een nieuwe server in dezelfde regio als de oorspronkelijke server die gebruikmaakt van de combinatie van volledige back-ups en back-ups van transactielogboeken.
  • Geo-herstel is alleen beschikbaar als u uw server hebt geconfigureerd voor geografisch redundante opslag. Hiermee kunt u uw server herstellen naar een andere regio met behulp van de meest recente back-up die u hebt gemaakt.

De geschatte tijd voor het herstel van de server is afhankelijk van verschillende factoren:

  • De grootte van de databases
  • Het aantal betrokken transactielogboeken
  • De hoeveelheid activiteit die opnieuw moet worden afgespeeld om te herstellen naar het herstelpunt
  • De netwerkbandbreedte als de herstelbewerking zich in een andere regio bevindt
  • Het aantal gelijktijdige herstelaanvragen dat wordt verwerkt in de doelregio
  • De aanwezigheid van primaire sleutel in de tabellen in de database. Voor sneller herstel kunt u overwegen om een primaire sleutel toe te voegen voor alle tabellen in uw database. Als u wilt controleren of uw tabellen een primaire sleutel hebben, kunt u de volgende query gebruiken:
select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

Voor een grote of zeer actieve database kan het herstel enkele uren duren. Als er een langdurige storing in een regio optreedt, kan het gebeuren dat een groot aantal aanvragen voor geo-herstel wordt geïnitieerd voor herstel na een noodgeval. Wanneer er veel aanvragen zijn, kan de hersteltijd voor individuele databases toenemen. De meeste herstelbewerkingen voor databases zijn in minder dan 12 uur voltooid.

Belangrijk

Verwijderde servers kunnen slechts binnen vijf dagen na verwijdering worden hersteld waarna de back-ups worden verwijderd. De databaseback-up kan alleen worden geopend en hersteld vanuit het Azure-abonnement dat als host fungeert voor de server. Raadpleeg de gedocumenteerde stappen om een verwijderde server te herstellen. Beheerders kunnen beheervergrendelingen gebruiken om serverbronnen te beveiligen, na de implementatie, tegen onbedoelde verwijdering of onverwachte wijzigingen.

Herstel naar een bepaald tijdstip

Onafhankelijk van de optie voor back-upredundantie kunt u een herstelbewerking uitvoeren naar een bepaald tijdstip binnen de bewaarperiode voor back-ups. Er wordt een nieuwe server gemaakt in dezelfde Azure-regio als de oorspronkelijke server. Deze wordt gemaakt met de configuratie van de oorspronkelijke server voor de prijscategorie, het genereren van berekeningen, het aantal vCores, de opslaggrootte, de bewaarperiode voor back-ups en de optie voor back-upredundantie.

Notitie

Er zijn twee serverparameters die na de herstelbewerking opnieuw worden ingesteld op standaardwaarden (en niet worden gekopieerd vanaf de primaire server)

  • time_zone : deze waarde die moet worden ingesteld op STANDAARDwaarde SYSTEM
  • event_scheduler - De event_scheduler is ingesteld op UIT op de herstelde server

U moet deze serverparameters instellen door de serverparameter opnieuw te configureren

Herstel naar een bepaald tijdstip is handig in meerdere scenario's. Wanneer een gebruiker bijvoorbeeld per ongeluk gegevens verwijdert, een belangrijke tabel of database verwijdert of als een toepassing per ongeluk goede gegevens overschrijft met slechte gegevens vanwege een toepassingsfout.

Mogelijk moet u wachten tot de volgende back-up van het transactielogboek is gemaakt voordat u binnen de afgelopen vijf minuten kunt herstellen naar een bepaald tijdstip.

Geo-herstel

U kunt een server herstellen naar een andere Azure-regio waar de service beschikbaar is als u uw server hebt geconfigureerd voor geografisch redundante back-ups.

  • Opslag v1-servers voor algemeen gebruik (die ondersteuning bieden voor maximaal 4 TB-opslag) kunnen worden hersteld naar de geografisch gekoppelde regio of naar een Azure-regio die ondersteuning biedt voor azure Database for MySQL - Single Server-service.
  • Opslag v2-servers voor algemeen gebruik (ondersteuning voor maximaal 16 TB-opslag) kunnen alleen worden hersteld naar Azure-regio's die ondersteuning bieden voor de infrastructuur voor opslag v2 voor algemeen gebruik. Raadpleeg de prijscategorieën van Azure Database for MySQL voor de lijst met ondersteunde regio's.

Geo-herstel is de standaardhersteloptie wanneer uw server niet beschikbaar is vanwege een incident in de regio waar de server wordt gehost. Als een grootschalig incident in een regio ertoe leidt dat uw databasetoepassing niet beschikbaar is, kunt u een server herstellen van de geografisch redundante back-ups naar een server in een andere regio. Geo-herstel maakt gebruik van de meest recente back-up van de server. Er is een vertraging tussen het moment waarop een back-up wordt gemaakt en wanneer deze naar een andere regio wordt gerepliceerd. Deze vertraging kan maximaal een uur duren, dus als er zich een noodgeval voordoet, kan er maximaal één uur gegevensverlies optreden.

Belangrijk

Als een geo-herstelbewerking wordt uitgevoerd voor een zojuist gemaakte server, kan de initiële back-upsynchronisatie meer dan 24 uur duren, afhankelijk van de grootte van de gegevens omdat de eerste volledige back-uptijd van de back-up veel hoger is. Volgende momentopnameback-ups zijn incrementele kopieën en daarom zijn de herstelbewerkingen na 24 uur na het maken van de server sneller. Als u geo-herstel evalueert om uw RTO te definiëren, raden we u aan om pas na 24 uur na het maken van servers te wachten en te evalueren voor betere schattingen.

Tijdens een geografisch herstel zijn de serverconfiguraties die kunnen worden gewijzigd onder andere: compute-generatie, vCore, bewaarperioden voor back-ups en opties voor redundantie van back-ups. Het wijzigen van de prijscategorie (Basic, Algemeen gebruik of Geoptimaliseerd voor geheugen) of de opslaggrootte tijdens geografisch herstel wordt niet ondersteund.

De geschatte duur van het herstel is afhankelijk van diverse factoren, waaronder de grootte van de databases, de transactielogboekgrootte, de netwerkbandbreedte en het totale aantal databases dat op hetzelfde moment in dezelfde regio moet worden hersteld. De hersteltijd is doorgaans minder dan 12 uur.

Taken na herstel uitvoeren

Nadat een herstelmechanisme is hersteld, moet u de volgende taken uitvoeren om uw gebruikers en toepassingen weer aan de slag te laten gaan:

  • Als de nieuwe server bedoeld is om de oorspronkelijke server te vervangen, stuurt u clients en clienttoepassingen om naar de nieuwe server
  • Zorg ervoor dat de juiste VNet-regels zijn ingesteld om gebruikers verbinding te laten maken. Deze regels worden niet gekopieerd van de oorspronkelijke server.
  • Zorg ervoor dat de juiste aanmeldingen en machtigingen op databaseniveau aanwezig zijn
  • Waarschuwingen configureren, indien van toepassing

Volgende stappen