Overzicht van bedrijfscontinuïteit met Azure Database for MariaDB

  • Artikel

Belangrijk

Azure Database for MariaDB bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan om te migreren naar Azure Database for MySQL. Zie Wat gebeurt er met Azure Database for MariaDB voor meer informatie over migreren naar Azure Database for MySQL.

In dit artikel worden de mogelijkheden beschreven die Azure Database for MariaDB biedt voor bedrijfscontinuïteit en herstel na noodgevallen. Meer informatie over opties voor het herstellen van verstorende gebeurtenissen die gegevensverlies kunnen veroorzaken of waardoor uw database en toepassing niet meer beschikbaar zijn. Meer informatie over wat u moet doen wanneer een gebruikersfout of toepassingsfout van invloed is op de gegevensintegriteit, een Azure-regio heeft een storing of als uw toepassing onderhoud nodig heeft.

Functies voor bedrijfscontinuïteit

Wanneer u uw bedrijfscontinuïteitsplan ontwikkelt, moet u het volgende begrijpen:

  • Beoogde hersteltijd (RTO):de maximale acceptabele tijd voordat de toepassing volledig herstelt na een verstorende gebeurtenis.
  • RPO (Recovery Point Objective): de maximale hoeveelheid recente gegevensupdates (tijdsinterval) die de toepassing kan tolereren dat verloren gaat wanneer deze wordt hersteld na een verstorende gebeurtenis.

Azure Database for MariaDB biedt functies voor bedrijfscontinuïteit en herstel na noodgevallen, waaronder geografisch redundante back-ups met de mogelijkheid om geo-herstel te initiëren en leesreplica's in een andere regio te implementeren. Elke functie heeft verschillende kenmerken voor de hersteltijd en het potentiële gegevensverlies.

Met geo-herstel maakt Azure Database for MariaDB een nieuwe server met behulp van de back-upgegevens die vanuit een andere regio worden gerepliceerd. De totale tijd die nodig is om te herstellen, is afhankelijk van de grootte van de database en de hoeveelheid logboekgegevens die moeten worden hersteld. De totale tijd voor het inrichten van de server varieert van enkele minuten tot enkele uren.

Met leesreplica's worden transactielogboeken van de primaire database asynchroon gestreamd naar een replica. Als er sprake is van een storing in de primaire database vanwege een zone- of regioniveaufout, biedt een failover naar de replica een kortere RTO en minder gegevensverlies.

Notitie

De vertraging tussen de primaire database en de replica is afhankelijk van de latentie tussen de sites, de hoeveelheid gegevens die moet worden verzonden en (belangrijkste) de schrijfworkload van de primaire server. Zware schrijfworkloads kunnen een aanzienlijke vertraging genereren.

Vanwege de asynchrone aard van de replicatie die wordt gebruikt voor leesreplica's, kunt u geen leesreplica's beschouwen als een oplossing voor hoge beschikbaarheid. De hogere vertragingen kunnen hogere RTO en RPO betekenen. Leesreplica's kunnen alleen fungeren als alternatief voor hoge beschikbaarheid voor workloads waarbij de vertraging kleiner blijft gedurende de piek- en daltijden. Anders zijn leesreplica's bedoeld voor echte leesschaal voor leesintensieve workloads en voor scenario's voor herstel na noodgevallen.

In de volgende tabel worden RTO en RPO vergeleken in een typisch workloadscenario :

Mogelijkheid Basis Algemeen gebruik Geoptimaliseerd voor geheugen
Herstel naar een bepaald tijdstip vanuit back-up Elk herstelpunt binnen de bewaarperiode
RTO varieert
RPO is minder dan 15 minuten		 Elk herstelpunt binnen de bewaarperiode
RTO varieert
RPO is minder dan 15 minuten		 Elk herstelpunt binnen de bewaarperiode
RTO varieert
RPO is minder dan 15 minuten
Geo-herstel vanuit geo-gerepliceerde back-ups Niet ondersteund RTO varieert
RPO is groter dan 24 uur		 RTO varieert
RPO is groter dan 24 uur
Leesreplica's RTO is minuten
RPO is minder dan 5 minuten		 RTO is minuten
RPO is minder dan 5 minuten		 RTO is minuten
RPO is minder dan 5 minuten

RTO en RPO kunnen in sommige gevallen veel hoger zijn, afhankelijk van factoren zoals latentie tussen sites, de hoeveelheid gegevens die moet worden verzonden en de schrijfworkload van de primaire database.

Herstel van een server na een gebruikers- of toepassingsfout

U kunt de back-ups van de service gebruiken om een server te herstellen van verschillende verstorende gebeurtenissen. Een gebruiker kan bijvoorbeeld per ongeluk bepaalde gegevens verwijderen, per ongeluk een belangrijke tabel verwijderen of zelfs een hele database verwijderen. Een toepassing kan per ongeluk goede gegevens overschrijven met slechte gegevens vanwege een toepassingsfout.

U kunt een herstel naar een bepaald tijdstip uitvoeren om een kopie van uw server te maken naar een bekend goed tijdstip. Dit tijdstip moet binnen de bewaarperiode voor back-ups vallen die u voor uw server hebt geconfigureerd. Nadat de gegevens zijn hersteld naar de nieuwe server, kunt u de oorspronkelijke server vervangen door de zojuist herstelde server of de benodigde gegevens van de herstelde server naar de oorspronkelijke server kopiëren.

Belangrijk

U kunt verwijderde servers slechts binnen vijf dagen na verwijdering herstellen. Na vijf dagen worden de back-ups verwijderd. U kunt de databaseback-up alleen openen en herstellen 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 beschermen tegen onbedoeld verwijderen of onverwachte wijzigingen na de implementatie.

Herstel na een storing in een regionaal Azure-datacenter

Hoewel het zeldzaam is, kan een Azure-datacenter een storing hebben. Wanneer er een storing optreedt, veroorzaakt dit een bedrijfsonderbreking die slechts een paar minuten kan duren, maar uren kan duren.

Een optie is om te wachten tot uw server weer online is wanneer de storing in het datacenter voorbij is. Wanneer het datacenter een storing heeft, weet u niet hoe lang de storing kan duren. Deze optie werkt dus alleen voor toepassingen die de server enige tijd offline kunnen hebben (bijvoorbeeld een ontwikkelomgeving).

Geo-herstel

Met de functie geo-herstel wordt de server hersteld met behulp van geografisch redundante back-ups. De back-ups worden gehost in de gekoppelde regio van uw server. Deze back-ups zijn toegankelijk, zelfs wanneer de regio waar uw server wordt gehost offline is. U kunt deze back-ups herstellen naar een andere regio en vervolgens uw server weer online brengen. Meer informatie over geo-herstel vindt u in het artikel over back-up- en herstelconcepten.

Belangrijk

Geo-herstel is alleen mogelijk als u de server hebt ingericht met geografisch redundante back-upopslag. Als u wilt overschakelen van lokaal redundante back-ups naar geografisch redundante back-ups voor een bestaande server, moet u een back-up van uw bestaande server genereren met behulp van mysqldump. Herstel vervolgens naar een zojuist gemaakte server die is geconfigureerd met geografisch redundante back-ups.

Leesreplica's in meerdere regio's

U kunt leesreplica's in meerdere regio's gebruiken om uw planning voor bedrijfscontinuïteit en herstel na noodgevallen te verbeteren. Leesreplica's worden asynchroon bijgewerkt via de replicatietechnologie van MySQL voor binaire logboeken. Meer informatie over leesreplica's, beschikbare regio's en hoe u een failover uitvoert in het artikel over leesreplicaconcepten.

Veelgestelde vragen

Waar worden klantgegevens opgeslagen in Azure Database for MariaDB?

Standaard worden in Azure Database for MariaDB geen klantgegevens verplaatst of opgeslagen uit de regio waar deze is geïmplementeerd. U kunt er echter voor kiezen om geografisch redundante back-ups in te schakelen of leesreplica's tussen regio's te maken voor het opslaan van gegevens in een andere regio.

Volgende stappen