Betrouwbaarheid in Azure Database for MySQL

Azure Database for MySQL is een volledig beheerde databaseservice die u gedetailleerde controle en flexibiliteit biedt voor databasebeheerfuncties en configuratie-instellingen. De service biedt mogelijkheden voor hoge beschikbaarheid (HA) en herstel na noodgevallen op basis van uw vereisten.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure Database for MySQL weerbaar kunt maken tegen verschillende mogelijke uitvalscenario’s en problemen, waaronder tijdelijke storingen, uitval van beschikbaarheidszones, regionale uitval en serviceonderhoud. Hierin wordt ook beschreven hoe u back-ups kunt gebruiken om te herstellen na andere soorten problemen en wordt belangrijke informatie over de service-level agreement (SLA) voor Azure Database for MySQL belicht.

Aanbevelingen voor productie-implementatie

Het Azure Well-Architected Framework biedt aanbevelingen voor betrouwbaarheid, beveiliging, kosten, bewerkingen en prestaties. Zie best practices voor architectuur voor Azure Database for MySQL om te begrijpen hoe deze gebieden van invloed zijn op elkaar en bijdragen aan een betrouwbare Azure Database for MySQL oplossing.

Overzicht van betrouwbaarheidsarchitectuur

In deze sectie worden enkele belangrijke aspecten beschreven van de werking van de service die het meest relevant is vanuit het perspectief van betrouwbaarheid. In de sectie wordt de logische architectuur geïntroduceerd, die enkele van de resources en functies bevat die u implementeert en gebruikt. Ook wordt de fysieke architectuur besproken, die details biedt over hoe de service achter de schermen werkt.

Logische architectuur

Wanneer u met Azure Database for MySQL werkt, implementeert u een server, die de reken- en opslagresources vertegenwoordigt die nodig zijn om uw databaseserver te ondersteunen. U implementeert een of meer databases op de server.

U kunt servers implementeren in de rekenlagen Burstable, Algemeen gebruik en Geoptimaliseerd voor geheugen. Elke rekenlaag is geoptimaliseerd voor verschillende soorten workloads.

Zie Azure Database for MySQL overzicht voor meer informatie over de algemene servicearchitectuur en implementatiemodellen.

Fysieke architectuur

• Compute- en opslagscheiding: Azure Database for MySQL maakt gebruik van een architectuur voor reken- en opslagscheiding ter ondersteuning van hoge beschikbaarheid. De database-engine wordt uitgevoerd op een virtuele machine (VM). Gegevensbestanden worden opgeslagen in Azure Storage, die synchroon drie kopieën van de gegevens onderhouden ter bescherming tegen hardwarestoringen in de opslag. Afhankelijk van de ha-configuratie van de server kunnen gegevensbestanden worden opgeslagen in zone-redundante opslag (ZRS) of lokaal redundante opslag (LRS).

• HA: U kunt desgewenst een HA-configuratie op uw server inschakelen. Wanneer u de HA-configuratie inschakelt, maakt de service een warme stand-by-replicaserver aan en onderhoudt deze. Gegevenswijzigingen op de primaire server worden synchroon gerepliceerd naar de stand-byreplicaserver om ervoor te zorgen dat er geen gegevens verloren gaan tijdens een storing van de primaire server.

  De architectuur scheidt de rekenlaag van de opslaglaag, waardoor de service op de juiste wijze verschillende typen fouten kan afhandelen. Voor een hogere tolerantie kunt u de servers over beschikbaarheidszones verdelen.

  Een stand-byreplicaserver wordt geïmplementeerd in dezelfde VM-configuratie als de primaire server, waaronder vCores, opslag en netwerkinstellingen.

  U kunt schakelen tussen servers door een failover uit te voeren. Gebruik niet-geplande failovers wanneer de primaire server mislukt en gebruik geplande failovers wanneer u de downtime van toepassingen tijdens een failover moet minimaliseren.

  Zie HA in Azure Database for MySQL voor meer informatie.

• Backups: Azure Database for MySQL maakt automatisch serverback-ups. Zie Back-up en herstel voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Uw toepassingen moeten tijdelijke verbindingsfouten afhandelen die kunnen optreden tijdens onderhoud, schaalbewerkingen of netwerkonderbrekingen. Volg deze aanbevelingen:

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek afzonderlijke groepen datacenters binnen een Azure regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Selecteer het type ondersteuning voor beschikbaarheidszones via de HA-configuratie. Wanneer u HA inschakelt, implementeert Azure Database for MySQL een stand-byreplicaserver naast uw primaire server. Dit HA-model helpt ervoor te zorgen dat vastgelegde gegevens nooit verloren gaan tijdens fouten. Welk HA-implementatiemodel u ook kiest, de service schrijft gegevens synchroon weg naar zowel de primaire server als de stand-byreplicaserver. Als de primaire server wordt onderbroken, voert de server automatisch een failover uit naar de stand-byreplicaserver.

De service slaat gegevens op in Azure Files Premium-opslag. Afhankelijk van de HA-configuratie van uw server wordt ZRS of LRS gebruikt, waarbij drie kopieën van gegevens binnen of verspreid over beschikbaarheidszones worden opgeslagen.

Azure Database for MySQL ondersteunt twee configuratietypen voor beschikbaarheidszones wanneer u ha gebruikt:

• Zone-redundante HA: Zoneredundantie biedt het hoogste niveau van weerbaarheid tegen zone-uitval doordat een primaire server in de ene beschikbaarheidszone en een replicaserver in stand-by in een andere beschikbaarheidszone worden geplaatst. De stand-byreplicaserver maakt gebruik van vergelijkbare reken-, opslag- en netwerkconfiguratie voor de primaire server. Een zone-redundante configuratie biedt fysieke isolatie van de hele stack tussen primaire en stand-byservers.

  U selecteert de beschikbaarheidszones voor de primaire en stand-byservers.

  Gebruik zone-redundante implementaties voor productieservers.

  

  Het diagram bestaat uit drie secties. De eerste sectie bevat clienttoepassingen zoals Azure VM's, Azure Kubernetes Service (AKS) en Azure App Service. De volgende sectie is gelabeld als beschikbaarheidszone 1. Deze bevat de primaire server en twee subsecties, berekening en opslag, gescheiden door een stippellijn. De derde sectie is gelabeld als beschikbaarheidszone 2. Deze spiegelt beschikbaarheidszone 1, maar bevat de stand-byserver. Pijlen wijzen van de clienttoepassingen naar een standaard load balancer. Eén pijl wijst van de load balancer naar een virtuele machine op de primaire server in beschikbaarheidszone 1. Tweerichtingspijlen verbinden de VM met de premium-bestandsshare en de SSD (solid-state drive). Nog een pijl wijst van premium-bestandsshare naar back-up-blobopslag. Een pijl met het label 'opslaggebaseerde asynchrone replicatie' wijst van beschikbaarheidszone 1 naar beschikbaarheidszone 2.

  Schrijfbewerkingen kunnen een kleine toename van doorvoerlatentie ervaren omdat de service synchroon gegevens repliceert naar de stand-byserver. Gemiddeld kunt u 5% tot 10% hogere latentie verwachten voor schrijfbewerkingen en doorvoeringen van toepassingen. De impact verschilt per workload, geselecteerde SKU en regio.

• Lokaal redundante HA: De primaire en stand-by-servers gebruiken dezelfde beschikbaarheidszone. Als er een onderbreking optreedt op de primaire server, maar de zone nog steeds in orde is, voert de server automatisch een failover uit naar de stand-byserver.

  Een lokaal redundante implementatie biedt u hoge beschikbaarheid binnen één beschikbaarheidszone. Het beschermt u tegen storingen op knooppuntniveau en helpt ook de downtime van toepassingen te verminderen tijdens geplande en ongeplande downtimegebeurtenissen. Het beschermt echter niet tegen een storing in die zone. In regio's met beschikbaarheidszones wordt dit type configuratie ook wel zonegebonden of één zone genoemd.

  

  Het diagram bestaat uit drie secties. De eerste sectie bevat clienttoepassingen zoals Azure VM's, AKS en App Service. De volgende sectie is gelabeld als beschikbaarheidszone 1. Het bevat twee afzonderlijke secties voor de primaire server en de stand-byserver. Een stippellijn verdeelt de sectie van elke server in twee subsecties, rekenkracht en opslag. Pijlen wijzen van de clienttoepassingen naar een standaard load balancer. Eén pijl wijst van de load balancer naar een virtuele machine op de primaire server in beschikbaarheidszone 1. Tweerichtingspijlen verbinden de VM en premium-bestandsshare en SSD (Solid-State Drive). Nog een pijl wijst van premium-bestandsshare naar back-up-blobopslag. Een pijl met het label opslaggebaseerde asynchrone replicatie wijst van de primaire server naar de stand-byserver. De derde sectie, gelabelde beschikbaarheidszone 2, is leeg.

  Gebruik alleen lokaal redundante ha in de volgende scenario's:

  • Wanneer u ongebruikelijk latentiegevoelige toepassingen hebt, valideert u de noodzaak om de latentie tussen uw primaire en secundaire replica te minimaliseren en plant u zonetolerantie met behulp van andere architectuurmethoden.

  • Wanneer u implementeert in een regio die geen beschikbaarheidszones ondersteunt. In dit scenario functioneert de regio als één beschikbaarheidszone, waardoor lokaal-redundante HA de enige HA-optie is.

  De servers bevinden zich in dezelfde zone, waardoor de schrijflatentie kan worden verminderd voor toepassingen die u in die zone implementeert.

Als u uw server zonder HA configureert, dan draait deze op één server. Als die server of de zone mislukt, is uw server niet beschikbaar.

Requirements

• Regioondersteuning: Azure Database for MySQL ondersteunt verschillende configuraties voor beschikbaarheidszones, afhankelijk van uw Azure regio. Zie Azure regio's voor een volledige lijst met regio's, inclusief typen ondersteuning voor beschikbaarheidszones en specifieke overwegingen voor elke regio.

• Servicelaag: Voor hoge beschikbaarheid zijn de lagen Algemeen gebruik of Geoptimaliseerd voor geheugen vereist. De Burstable-tier ondersteunt geen HA (zone-redundant of lokaal-redundant).

Cost

Wanneer u hoge beschikbaarheid inschakelt, richt u de stand-byserver in en betaalt u daarvoor tegen hetzelfde tarief als voor de primaire server. De configuratie van de beschikbaarheidszone heeft geen invloed op de kosten. Voor gegevensreplicatie worden geen kosten in rekening gebracht binnen of tussen beschikbaarheidszones. Afhankelijk van uw back-upopslagvolume, wordt u mogelijk ook gefactureerd voor back-upopslag. Zie Azure Database for MySQL prijzen voor gedetailleerde prijsinformatie.

Overwegingen

• Primaire sleutels: Gebruik primaire sleutels voor alle tabellen omdat deze aanpak de replicatie- en failovertijd vermindert.

• Beperkingen en bekende problemen: Bekijk de lijst met beperkingen en bekende problemen.

Ondersteuning voor beschikbaarheidszones configureren

Als u ondersteuning voor beschikbaarheidszones voor een server wilt configureren, configureert u de ha-instellingen.

• Maak een zone-redundante server. Zie de volgende artikelen voor meer informatie over het maken van een server met hoge beschikbaarheid en zoneredundantie:

  • Azure portal: Zone-redundante ha in Azure Database for MySQL beheren met behulp van de Azure-portal.

  • Azure CLI: Zone-redundante ha in Azure Database for MySQL beheren met behulp van de Azure CLI.

• Maak een lokaal redundante server. Als u een server met lokaal redundante ha in één beschikbaarheidszone wilt maken, moet u de Azure CLI of een andere programmatische implementatiemethode gebruiken. Zie Ha inschakelen tijdens het maken van de server voor de Azure CLI instructies.

• Wijzig de configuratie van de beschikbaarheidszone voor bestaande servers. Als u een bestaande server hebt, is de methode die u volgt om ondersteuning voor beschikbaarheidszones in te schakelen afhankelijk van de eerste configuratie van de server.

  • Als u een bestaande server wilt omzetten naar zone-redundante hoge beschikbaarheid (HA), moet u migreren naar een nieuwe server. Zie Migreren van een bestaande server naar een zone-redundante server voor meer informatie.

  • Een bestaande server wijzigen naar lokaal redundante HA:

    1. Schakel HA uit als deze is ingeschakeld.

    2. Lokaal redundante HA inschakelen. U moet de Azure CLI of een andere programmatische implementatiemethode gebruiken. Zie zone-redundante HA in Azure Database for MySQL beheren met behulp van de Azure CLI voor instructies voor Azure CLI.

• HA uitschakelen. Als u HA uitschakelt, wordt de replicaserver in stand-by verwijderd, waardoor uw server niet veerkrachtig is bij uitval op zoneniveau. Als geografisch redundante back-ups echter zijn ingeschakeld, kunt u de server in een andere regio nog steeds herstellen met behulp van deze back-ups. Zie Ha uitschakelen voor meer informatie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u servers configureert met ondersteuning voor hoge beschikbaarheidszones en alle beschikbaarheidszones operationeel zijn.

• Bewerking tussen zones: MySQL-clienttoepassingen maken verbinding met de primaire server met behulp van de FQDN (Fully Qualified Domain Name) van de databaseserver. Vermijd het gebruik van het IP-adres van de primaire server omdat het IP-adres kan worden gewijzigd, ook tijdens failovers.

  Azure Database for MySQL maakt gebruik van een actief-passieve configuratie waarin de primaire server alle databaseverbindingen en query's in de primaire beschikbaarheidszone verwerkt. De stand-byreplicaserver verwerkt geen clientverkeer tijdens normale bewerkingen.

• Replicatie van gegevens in meerdere zones: Schrijfbewerkingen worden doorgevoerd op de primaire server en synchroon naar logboeken voor de stand-byserver geschreven met behulp van ZRS. De primaire server wacht niet totdat de stand-byserver de logboeken toepast, maar omdat de logboeken zich in ZRS bevinden, zijn ze beschikbaar, zelfs als er een replica- of zonefout optreedt.

  De gevolgen van replicatie verschillen, afhankelijk van de configuratie van de beschikbaarheidszone die uw server gebruikt:

  • Zone-redundant: Omdat de servers zich in afzonderlijke zones bevinden, zorgt deze benadering ervoor dat er geen gegevens verloren gaan tijdens een zonefout. Deze situatie staat ook bekend als het bereiken van een Recovery Point Objective (RPO) van nul bij zonefouten.

    Replicatie tussen zones kan echter een kleine hoeveelheid extra latentie veroorzaken. Gemiddeld kunt u 5% tot 10% hogere latentie verwachten voor schrijf- en doorvoerbewerkingen van toepassingen, maar de impact verschilt per workload, geselecteerde SKU en regio.

  • Lokaal-redundant: Er wordt geen verkeer tussen zones gerepliceerd.

  Opmerking

  Het systeem repliceert alle wijzigingen in realtime naar de stand-byreplicaserver, inclusief onbedoelde gebruikersfouten, zoals een onbedoelde daling van een tabel of onjuiste gegevensupdates. Vanwege de directe replicatie kunt u de stand-byreplica niet gebruiken voor herstel. Om te herstellen van gebruikersfouten, moet u een herstel op een bepaald moment uitvoeren vanuit een back-up. Zie Back-up en herstel voor meer informatie.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u servers configureert met ondersteuning voor beschikbaarheidszones en er een storing in de beschikbaarheidszone is.

• Detection en response: Azure controleert regelmatig de status van de primaire en stand-byservers. Als na meerdere pings gezondheidsbewaking detecteert dat een primaire server niet bereikbaar is, start de service een automatische failover naar de standby-server. Het algoritme voor statuscontrole gebruikt meerdere gegevenspunten om fout-positieve situaties te voorkomen.

  Als er een zonefout optreedt, verschilt het gedrag, afhankelijk van de configuratie van de beschikbaarheidszone die uw server gebruikt:

  • Zone-redundant: Azure Database for MySQL detecteert automatisch storingen in de beschikbaarheidszone door continu meerdere servereindpunten te bewaken. Zie Hoe automatische failoverdetectie werkt in servers met hoge beschikbaarheid voor meer informatie.

    Als u de mogelijke HA-statustypen wilt zien, raadpleegt u HA bewaken. Wanneer een zone mislukt, start Azure een onplande failover naar de stand-byserver zonder dat u actie hoeft te ondernemen.

  • Lokaal redundant: Zowel primaire als stand-byservers zijn niet beschikbaar als de beschikbaarheidszone die als host fungeert voor een lokaal redundante server niet meer beschikbaar is. In dit scenario biedt de service geen automatische failover. U bent verantwoordelijk voor het detecteren van de zonestoring en het uitvoeren van herstelacties, zoals het herstellen van zone-redundante back-ups naar een afzonderlijke server in een andere beschikbaarheidszone of regio.

• Notification: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt echter Azure Resource Health gebruiken om de status van een afzonderlijke resource te controleren en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt ook Azure Service Health gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Servicestatuswaarschuwingen instellen om u op de hoogte te stellen van problemen.

  Azure Database for MySQL genereert een Azure Resource Health gebeurtenis wanneer er een niet-geplande failover plaatsvindt.

• Actieve aanvragen: Wanneer een beschikbaarheidszone niet beschikbaar is, kunnen aanvragen die worden uitgevoerd voor servers in de betrokken zone, worden beëindigd. Toepassingen moeten deze aanvragen opnieuw proberen. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

• Verwachte gegevensverlies: De hoeveelheid gegevensverlies is afhankelijk van de configuratie van de beschikbaarheidszone van uw server.

  • Zone-redundant: Er wordt geen gegevensverlies verwacht tijdens zonefailover vanwege synchrone replicatie tussen de primaire en stand-byservers in verschillende zones.

  • Lokaal redundant: Gegevens op servers in de getroffen zone zijn niet beschikbaar totdat de zone wordt hersteld.

• Verwachte downtime: De hoeveelheid downtime is afhankelijk van de configuratie van de beschikbaarheidszone die door uw server wordt gebruikt.

  • Zone-redundant: Failover wordt doorgaans binnen 60 tot 120 seconden voltooid. Als uw clients tijdelijke fouten op de juiste wijze afhandelen door het opnieuw te proberen na een korte periode, worden meestal aanzienlijke gevolgen vermeden.

  • Lokaal redundant: Servers in een getroffen zone zijn niet beschikbaar totdat de beschikbaarheidszone wordt hersteld.

• Herverdeling: Het gedrag voor het omleiden van verkeer is afhankelijk van de configuratie van de beschikbaarheidszone die door uw server wordt gebruikt.

  • Zone-redundant: Na een failover wordt de stand-byserver de nieuwe primaire server en begint de nieuwe verbindingen te accepteren. Azure maakt automatisch een stand-byserver in de oorspronkelijke primaire zone nadat deze is hersteld. Zie Niet-geplande failover voor meer informatie.

  • Lokaal redundant: Wanneer een zone niet beschikbaar is, is uw server niet beschikbaar. Als u een afzonderlijke server hebt die u vooraf hebt gemaakt in een andere beschikbaarheidszone of regio, bent u verantwoordelijk voor het opnieuw routeren van verkeer naar die server.

Zoneherstel

Het gedrag van zoneherstel is afhankelijk van de configuratie van de beschikbaarheidszone die door uw server wordt gebruikt.

• Zone-redundant: Wanneer de beschikbaarheidszone wordt hersteld, Azure Database for MySQL de stand-byserver automatisch opnieuw opbouwen in de herstelde zone en synchroniseert deze met de huidige primaire server. De herstelde zone fungeert vervolgens als de stand-bylocatie. De dienst verplaatst de primaire rol niet automatisch terug naar de oorspronkelijke zone om onnodige verstoringen te voorkomen. Als u de primaire zone wilt terugsturen naar de oorspronkelijke zone, kunt u handmatig een geplande failover initiëren.

• Lokaal redundant: Nadat de zone gezond is, zijn de servers in de zone weer beschikbaar. U bent verantwoordelijk voor zoneherstelprocedures en gegevenssynchronisatie die uw workloads nodig hebben.

Testen op zonefouten

De opties voor het testen van zonefouten zijn afhankelijk van de configuratie van de beschikbaarheidszone die door uw exemplaar wordt gebruikt.

• Zone-redundant: U kunt de tolerantie van uw toepassing voor failover testen door een geplande failover te starten. Gebruik een geplande failover om een ongeplande storing te simuleren terwijl uw workload wordt uitgevoerd, en observeer de downtime van uw toepassing. Voer simulaties uit in niet-productieomgevingen of op een rustige tijd. Zie Geplande failover voor meer informatie.

• Lokaal redundant: U kunt geen volledige zonestoring simuleren, maar u kunt simuleren dat uw server niet beschikbaar is op een vergelijkbare manier als wat er gebeurt tijdens een zonestoring. Zie de volgende artikelen voor meer informatie:

  • Azure portal: Stop en start een Azure Database for MySQL flexibele serverinstantie.

  • Azure CLI: start een Azure Database for MySQL flexibele serverinstantie opnieuw op, stop en start deze.

Tolerantie voor storingen in de hele regio

Azure Database for MySQL ondersteunt leesreplica's in meerdere regio's, die u kunt gebruiken om een gesynchroniseerde kopie van uw database in een andere regio te onderhouden voor sneller herstel.

U kunt ook geografisch redundante back-ups in ondersteunde regio's gebruiken om herstel tussen regio's mogelijk te maken. Back-ups hebben echter meestal meer downtime en gegevensverlies dan replicatie. Zie Back-up en herstel voor meer informatie.

Leesreplica's in meerdere regio's

Implementeer leesreplica’s om uw databases te beschermen tegen uitval op regioniveau. Elke leesreplica is een afzonderlijke Azure Database for MySQL-server. Wanneer u een leesreplica in een tweede Azure regio plaatst, kan uw databaseserver tolerantie bieden voor een probleem in de hele regio. U kunt maximaal 10 leesreplica's implementeren, die zich eventueel in verschillende Azure-regio's kunnen bevinden.

Updates voor fysieke replicatietechnologie van MySQL lezen replica's asynchroon van de bronserver in de primaire regio, wat betekent dat replica's achter de bron kunnen blijven. Regio-overschrijdende leesreplica's kunnen optioneel alleen-lezenworkloads verwerken om de latentie voor wereldwijd gedistribueerde toepassingen te verminderen of het leesverkeer van de bronserver te ontlasten. Zie leesreplica’s voor meer informatie over de functies van leesreplica’s en aandachtspunten.

Als uw primaire regio uitvalt, kunt u handmatig een failover uitvoeren om de secundaire replica de primaire server te maken. Als u handmatig een failover wilt uitvoeren, stopt u het replicatieproces, waardoor de leesreplica naar een lees-/schrijfserver wordt gepromoot. Vanwege de asynchrone replicatie kan failover leiden tot gegevensverlies. Uw toepassing moet verbinding maken met de nieuwe primaire server en u bent verantwoordelijk voor het opnieuw configureren van toepassingen.

Requirements

• Regio-ondersteuning: U kunt leesreplica's in meerdere regio's maken in elke regio die ondersteuning biedt voor Azure Database for MySQL. U bent niet beperkt tot Azure gekoppelde regio's.

• Rekenlagen: De rekenlagen General Purpose en Memory Optimized ondersteunen leesreplica's. De laag Burstable biedt geen ondersteuning voor leesreplica's.

Overwegingen

• Configuratieverschillen: Wanneer u een replica maakt, neemt deze verschillende instellingen over van de bronserver, waaronder de berekeningsgeneratie, vCores en opslag. U kunt deze waarden op de leesreplica aanpassen nadat u deze hebt gemaakt, maar u kunt het beste gelijke of hogere waarden gebruiken om ervoor te zorgen dat de replica wijzigingen in de bron kan bijhouden.

• Replicatievertraging bewaken: Voor het asynchrone replicatieproces is een replicatievertraging vereist, die kan variëren, afhankelijk van verschillende factoren. Wanneer de replicatievertraging erg hoog is, kan uw server problemen ondervinden. Het is belangrijk om de replicatievertraging te bewaken, zodat u problemen kunt beperken voordat ze escaleren. Zie voor meer informatie Replicatie bewaken.

• HA: Voor leesreplica’s kan hoge beschikbaarheid niet worden ingeschakeld, en wanneer er een failover naar de primaire server plaatsvindt, hebben ze ook geen hoge beschikbaarheid. U bent verantwoordelijk voor het configureren van HA na een failover naar een replica.

Cost

Read-replica's brengen reken- en opslagkosten in rekening, evenals kosten tussen regio's voor gegevensoverdracht voor replicatie. Zie Azure Database for MySQL pricing and Bandwidth pricing voor gedetailleerde prijsinformatie.

Ondersteuning voor meerdere regio's configureren

• Een leesreplica maken: Zie de volgende artikelen voor meer informatie over het maken van een leesreplica:

  • Azure portal: Leesreplica's maken en beheren in Azure Database for MySQL flexibele server met behulp van de Azure-portal

  • Azure CLI: Leesreplica's maken en beheren in Azure Database for MySQL flexibele server met behulp van de Azure CLI

  U kunt replica's configureren nadat u de bronserver alleen hebt gemaakt als de bronserver wordt uitgevoerd en bereikbaar is.

• Replicatie stoppen: Zie Replicatie stoppen naar een replicaserver voor meer informatie over het stoppen van replicatie.

• Een leesreplica verwijderen: Voor instructies over het verwijderen van een leesreplica, zie Een replicaserver verwijderen.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u uw server configureert met een leesreplica in een andere regio en alle regio's operationeel zijn:

• Verkeersroutering tussen regio's: Tijdens normale bewerkingen moet uw toepassing lees-/schrijfverkeer omleiden naar de bronserver in de primaire regio. U kunt desgewenst leesaanvragen naar uw leesreplica doorsturen.

• Gegevensreplicatie tussen regio's: Leesreplica's in meerdere regio's maken gebruik van asynchrone replicatie om de impact op de prestaties van de bronserver te minimaliseren. De hoeveelheid replicatievertraging is afhankelijk van verschillende factoren, waaronder de schrijfbelasting en de latentie tussen de bronserver en replica's. Replicatievertraging duurt doorgaans minstens enkele minuten, maar kan veel langer zijn. Zie Monitor replication en zie Monitor replication in the Azure portal voor meer informatie.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een server configureert voor ondersteuning van leesreplica's in meerdere regio's en als er een storing is in de primaire regio.

• Detectie en reactie: U bent verantwoordelijk voor het detecteren van een storing in de primaire regio en het handmatig activeren van een failover. Deze actie kan leiden tot het verlies van niet-gerepliceerde gegevens.

  Belangrijk

  U bent verantwoordelijk voor het activeren van failover. Azure voert geen failover uit om replica's automatisch te lezen, zelfs niet als er een regiofout optreedt.

  Voor failover moet u de volgende stappen uitvoeren:

  1. Stop de replicatie. Deze procedure kan niet ongedaan worden gemaakt en de server kan niet opnieuw in een replica worden gemaakt. Het proces leidt tot gegevensverlies. Zie Replicatie stoppen voor meer informatie over de gevolgen van deze actie.

  2. Configureer uw toepassing opnieuw om de nieuwe primaire server te gebruiken.

  Zie Failovervoor meer informatie.

• Notification: Microsoft geeft u niet automatisch een melding wanneer een regio uitvalt. U kunt echter Azure Service Health gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Statuswaarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Alle actieve verbindingen met de bronregio worden verwijderd als de bronserver niet beschikbaar is. Toepassingen moeten opnieuw verbinding maken met de nieuwe primaire server nadat het failoverproces is voltooid.

• Verwachte gegevensverlies: Tijdens een regio-storing moet u een failover uitvoeren die de replicatie stopt. Dit proces leidt tot permanent verlies van niet-gerepliceerde gegevens.

  De hoeveelheid gegevensverlies is afhankelijk van de replicatievertraging op het moment van de storing. Replicatievertraging duurt doorgaans minstens enkele minuten, maar kan veel langer zijn. Zie voor meer informatie Replicatie bewaken.

• Verwachte downtime: Het stoppen van de replicatie wordt doorgaans binnen twee minuten voltooid nadat u de actie hebt geactiveerd. U bent verantwoordelijk voor het opnieuw configureren van uw toepassingen om verbinding te maken met de nieuwe primaire server. De tijd die nodig is om de herconfiguratie uit te voeren, draagt ook bij aan uw algehele downtime.

• Verkeer omleiden: U bent verantwoordelijk voor het opnieuw configureren van uw toepassingen om verbinding te maken met de nieuwe primaire server.

  Opmerking

  Nadat u een failover van een leesreplica hebt uitgevoerd zodat deze de primaire server wordt, is hoge beschikbaarheid niet ingeschakeld op de server. U moet HA handmatig inschakelen of opnemen in uw automatisering.

Herstel van de regio

Wanneer de regio is hersteld, bent u verantwoordelijk voor failback-activiteiten om de activiteiten in de primaire regio te hervatten. Microsoft verplaatst de primaire server niet automatisch. U kunt een nieuwe leesreplica maken in de primaire regio en vervolgens een ander failoverproces uitvoeren om bewerkingen in de primaire regio te herstellen. Houd rekening met een van de volgende benaderingen, afhankelijk van of uw toepassing downtime of gegevensverlies kan tolereren:

• Haal uw toepassing offline en wacht totdat de replicatie alle wijzigingen heeft bijgehaald. Voor deze aanpak is downtime van toepassingen vereist die ongeveer hetzelfde is als de replicatievertraging.

• Voer de failover uit en accepteer het verlies van niet-gerepliceerde gegevens.

Houd er rekening mee dat u ook verantwoordelijk bent voor het opnieuw configureren van uw toepassingen om verbinding te maken met de nieuwe primaire server, indien nodig.

Test voor regiofouten

Test regelmatig leesfailoverprocedures om ervoor te zorgen dat uw processen geldig zijn en dat de mogelijkheden voldoen aan uw vereisten voor hersteltijddoelstelling (RTO) en RPO.

U kunt op elk gewenst moment een failover van een leesreplica uitvoeren om de primaire server te worden, zelfs wanneer alle regio's in orde zijn. We raden u aan deze tests uit te voeren in een niet-productieomgeving, omdat dit gegevensverlies kan veroorzaken en handmatige failback vereist.

Voer als onderdeel van uw DR-strategie regelmatig volledige hersteloefeningen uit. Deze oefeningen omvatten gegevensvalidatie, testen van toepassingsfunctionaliteit en gedocumenteerde procedures voor terugdraaien.

Backups en herstel

Azure Database for MySQL automatisch een back-up van uw gegevens maakt, zodat u deze op elk gewenst moment binnen de bewaarperiode van de back-up kunt herstellen. Deze beveiliging helpt u onbedoelde beschadiging en verwijdering van gegevens te voorkomen. Microsoft de back-ups volledig beheert zonder de beschikbaarheid van de server te onderbreken. De back-ups bevatten zowel volledige back-ups als back-ups van transactielogboeken.

• Back-upopslag: Als u de server configureert met zone-redundante hoge beschikbaarheid (HA), slaat het systeem back-ups op in ZRS. Voor servers die zijn geconfigureerd zonder HA of met lokaal redundante HA, slaat het systeem back-ups op in LRS.

  In Azure regio's met paren kunt u geografisch redundante opslag (GRS) configureren voor back-ups wanneer u de server maakt. Met deze methode worden back-ups gerepliceerd naar de Azure gekoppelde regio voor extra beveiliging tegen regiofouten. Het systeem repliceert asynchroon back-ups.

  De standaardretentieperiode voor back-ups is 7 dagen, maar u kunt de retentie uitbreiden tot 35 dagen. Alle back-ups worden versleuteld.

• Herstellen: Met herstel naar een bepaald tijdstip (PITR) kunt u uw database herstellen naar elk moment binnen de bewaarperiode voor back-ups. Het herstelproces maakt een nieuwe databaseserver met een nieuwe servernaam die door de gebruiker is verstrekt. U kunt de nieuwe server gebruiken as-is of gegevens kopiëren.

  Wanneer u een geografisch redundante back-up herstelt, maakt u een nieuwe server in de gekoppelde regio. In sommige regio's kunt u Universal Geo-Restore gebruiken om een geografisch redundante back-up te herstellen naar een regio die niet de gekoppelde regio van uw primaire regio is.

  Gebruik deze mogelijkheid om te herstellen van onbedoelde gegevenswijzigingen, toepassingsfouten of testscenario's.

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Wat zijn redundantie, replicatie en back-up? voor meer informatie.

Zie Backup en herstel in Azure Database for MySQL voor meer informatie.

Tolerantie voor serviceonderhoud

Azure Database for MySQL verwerkt automatisch kritieke onderhoudstaken, waaronder het patchen van de onderliggende hardware, het besturingssysteem en de database-engine. De service bevat beveiligingsupdates, software-updates en secundaire versie-upgrades als onderdeel van gepland onderhoud. Zie Scheduled onderhoud in Azure Database for MySQL voor meer informatie.

Volg deze aanbevelingen om ervoor te zorgen dat uw server beschikbaar blijft tijdens onderhoudsvensters:

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLAs voor onlineservices voor meer informatie.

Azure Database for MySQL biedt verschillende beschikbaarheidS-SLA's op basis van de configuratie van de server:

• Servers geconfigureerd met zone-redundante HA.
• Servers geconfigureerd voor lokaal-redundante hoge beschikbaarheid.
• Servers geconfigureerd zonder HA.

Verwante inhoud

• Azure betrouwbaarheid
• Architectuur best practices voor Azure Database for MySQL
• Overzicht van bedrijfscontinuïteit met Azure Database for MySQL