Overzicht van bedrijfscontinuïteit met Azure Database for MariaDB

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 ertoe kunnen leiden dat uw database en toepassing niet meer beschikbaar zijn. Meer informatie over wat u moet doen wanneer een gebruikers- of toepassingsfout van invloed is op de gegevensintegriteit, een Azure-regio een storing heeft of uw toepassing onderhoud vereist.

Functies die u kunt gebruiken om bedrijfscontinuïteit te bieden

Wanneer u uw bedrijfscontinuïteitsplan ontwikkelt, moet u de maximaal aanvaardbare tijd begrijpen voordat de toepassing volledig wordt hersteld na de verstorende gebeurtenis. Dit is uw Beoogde hersteltijd (RTO). U moet ook inzicht hebben in de maximale hoeveelheid recente gegevensupdates (tijdsinterval) die de toepassing kan tolereren bij het herstellen na de verstorende gebeurtenis- dit is uw Recovery Point Objective (RPO).

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-herstelfunctie wordt een nieuwe server gemaakt 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 logboeken 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 replica asynchroon naar de replica gestreamd. In het geval van een primaire databasestoring als gevolg van een fout op zone- of regioniveau, biedt een failover naar de replica een kortere RTO en minder gegevensverlies.

Notitie

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

Vanwege de asynchrone aard van replicatie die wordt gebruikt voor leesreplica's, moeten ze niet worden beschouwd als een oplossing voor hoge beschikbaarheid (HA), omdat de hogere vertragingen een hogere RTO en RPO kunnen betekenen. Alleen voor workloads waarbij de vertraging kleiner blijft tijdens de piek- en niet-piektijden van de werkbelasting, kunnen leesreplica's fungeren als alternatief voor hoge beschikbaarheid. Anders zijn leesreplica's bedoeld voor echte leesschaal voor kant-en-klare zware werkbelastingen en voor scenario's met herstel na noodgevallen.

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

Mogelijkheid Basic Algemeen doel Geoptimaliseerd voor geheugen
Herstel naar een bepaald tijdstip vanuit back-up Elk herstelpunt binnen de RTO van de bewaarperiode - RPO < varieert 15 min. Elk herstelpunt binnen de RTO van de bewaarperiode - RPO < varieert 15 min. Elk herstelpunt binnen de RTO van de bewaarperiode - RPO < varieert 15 min.
Geo-herstel vanuit geo-gerepliceerde back-ups Niet ondersteund RTO - RPO < varieert 1 uur RTO - RPO < varieert 1 uur
Leesreplica's RTO - minuten* RPO < 5 min* RTO - minuten* RPO < 5 min* RTO - minuten* RPO < 5 min*

* RTO en RPO kunnen in sommige gevallen veel hoger zijn , afhankelijk van verschillende factoren, waaronder latentie tussen sites, de hoeveelheid gegevens die moet worden verzonden en belangrijke werkbelasting voor het schrijven van primaire databases.

Een server herstellen 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 per ongeluk bepaalde gegevens verwijderen, per ongeluk een belangrijke tabel verwijderen of zelfs een hele database verwijderen. Een toepassing kan per ongeluk goede gegevens met slechte gegevens overschrijven vanwege een toepassingsfout, enzovoort.

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 retentieperiode voor back-ups liggen 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 kopiëren naar de oorspronkelijke server.

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 serverresources na de implementatie te beschermen tegen onbedoelde verwijdering of onverwachte wijzigingen.

Herstellen van een storing in een regionaal Azure-datacenter

Hoewel zeldzaam, kan er een storing optreden in een Azure-datacenter. Wanneer er een storing optreedt, veroorzaakt dit een bedrijfsonderbreking die mogelijk slechts enkele minuten duurt, maar uren kan duren.

Een optie is om te wachten totdat uw server weer online komt wanneer de storing in het datacenter voorbij is. Dit werkt voor toepassingen die het zich kunnen veroorloven om de server enige tijd offline te hebben, bijvoorbeeld een ontwikkelomgeving. Wanneer er een storing optreedt in het datacenter, weet u niet hoe lang de storing kan duren. Deze optie werkt dus alleen als u uw server een tijdje niet nodig hebt.

Geo-herstel

De functie geo-herstel herstel herstelt de server met behulp van geografisch redundante back-ups. De back-ups worden gehost in de gekoppelde regio van uw server. Deze back-ups zijn zelfs toegankelijk wanneer de regio waarin uw server wordt gehost offline is. U kunt vanuit deze back-ups terugzetten naar een andere regio en uw server weer online brengen. Meer informatie over geo-herstel vindt u in het artikel over concepten voor back-up en herstel.

Belangrijk

Geo-herstel is alleen mogelijk als u de server hebt ingericht met geografisch redundante back-upopslag. Als u wilt overschakelen van lokaal redundante naar geografisch redundante back-ups voor een bestaande server, moet u een dump maken met behulp van mysqldump van uw bestaande server en deze herstellen 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 bedrijfscontinuïteit en noodherstelplanning te verbeteren. Leesreplica's worden asynchroon bijgewerkt met behulp van de replicatietechnologie voor binaire logboeken van MySQL. Meer informatie over leesreplica's, beschikbare regio's en het uitvoeren van een failover vindt u in het artikel Concepten van leesreplica's.

Veelgestelde vragen

Waar slaat Azure Database for MariaDB klantgegevens op?

Standaard verplaatst of slaat Azure Database for MariaDB klantgegevens niet op uit de regio waarin het is geïmplementeerd. Klanten kunnen er echter optioneel voor kiezen om geografisch redundante back-ups in te schakelen of leesreplica's voor meerdere regio's te maken voor het opslaan van gegevens in een andere regio.

Volgende stappen