Hoge beschikbaarheid in Azure Database for MySQL

Met behulp van Azure Database for MySQL Flexibele server kunt u hoge beschikbaarheid configureren met automatische failover. Deze oplossing zorgt ervoor dat fouten nooit leiden tot verlies van vastgelegde gegevens en dat de database geen single point of failure is in uw softwarearchitectuur. Wanneer u hoge beschikbaarheid configureert, richt Flexible Server automatisch een stand-by-Hyper-V replica in en beheert deze. U betaalt voor de ingerichte rekenkracht en storage voor zowel de primaire als de secundaire replica's. Er zijn twee architectuurmodellen met hoge beschikbaarheid beschikbaar:

  • Zone-redundante beschikbaarheid met hoge betrouwbaarheid. Deze optie biedt volledige isolatie en redundantie van infrastructuur in meerdere availability zones. Het biedt het hoogste beschikbaarheidsniveau, maar hiervoor moet u toepassingsredundantie tussen zones configureren. Kies zone-redundante hoge beschikbaarheid wanneer u wilt beveiligen tegen infrastructuurfouten in de beschikbaarheidszone en wanneer latentie in de beschikbaarheidszone acceptabel is. U kunt zone-redundante hoge beschikbaarheid alleen inschakelen wanneer u de server maakt. Zone-redundante hoge beschikbaarheid is beschikbaar in een subset van Azure regio's waar de regio ondersteuning biedt voor meerdere beschikbaarheidszones en zone-redundante Premium-bestandsshares beschikbaar zijn.

  • Lokale redundante hoge beschikbaarheid. Deze optie biedt infrastructuurredundantie met lagere netwerklatentie omdat de primaire en stand-byservers zich in dezelfde beschikbaarheidszone bevinden. Het biedt hoge beschikbaarheid zonder dat toepassingsredundantie tussen zones hoeft te worden geconfigureerd. Kies lokale redundante hoge beschikbaarheid wanneer u het hoogste beschikbaarheidsniveau binnen één beschikbaarheidszone met de laagste netwerklatentie wilt bereiken. Lokale redundante hoge beschikbaarheid is beschikbaar in alle Azure regio's waar u Azure Database for MySQL Flexible Server kunt gebruiken.

Architectuur met zone-redundante hoge beschikbaarheid (HA)

Wanneer u een server met zone-redundante hoge beschikbaarheid implementeert, maakt Azure twee servers:

  • Een primaire server in één beschikbaarheidszone.
  • Een stand-by-replicaserver in een andere beschikbaarheidszone van dezelfde Azure-regio. De stand-byreplicaserver heeft dezelfde configuratie als de primaire server, waaronder de rekenlaag, rekenkracht, storage grootte en netwerkconfiguratie.

Diagram met de architectuur voor zone-redundante hoge beschikbaarheid.

U kunt de beschikbaarheidszone kiezen voor zowel de primaire server als de stand-by replica. Als u de primaire server en de stand-byserver in dezelfde zone plaatst, vermindert u de latentie, terwijl u ze in verschillende zones plaatst, zodat u zich kunt voorbereiden op situaties met herstel na noodgevallen en scenario's voor zone-down.

De gegevens en logboekbestanden worden gehost in zone-redundante storage (ZRS). De stand-byserver leest en speelt de logbestanden continu af vanuit het storage-account van de primaire server, dat replicatie op storage-niveau beveiligt.

Als er een failover optreedt:

  • De stand-byreplica wordt geactiveerd.
  • De binaire logboekbestanden van de primaire server blijven van toepassing op de stand-byserver om deze online te brengen naar de laatste doorgevoerde transactie op de primaire server.

Logboeken in ZRS zijn toegankelijk, zelfs wanneer de primaire server niet beschikbaar is. Deze beschikbaarheid helpt ervoor te zorgen dat er geen gegevens verloren gaan. Nadat de stand-byreplica is geactiveerd en binaire logboeken zijn toegepast, neemt de huidige stand-byreplicaserver de rol van de primaire server. DNS-updates zodat clientverbindingen rechtstreeks naar de nieuwe primaire server worden verzonden wanneer de client opnieuw verbinding maakt. De failover is volledig transparant vanuit de clienttoepassing en vereist geen actie van u. De ha-oplossing brengt vervolgens de oude primaire server indien mogelijk terug en plaatst deze als stand-by.

U gebruikt de naam van de databaseserver om toepassingen te verbinden met de primaire server. De oplossing biedt geen stand-by replica-informatie voor directe toegang. Doorvoeringen en schrijfbewerkingen worden bevestigd nadat de logboekbestanden zijn leeggemaakt op de ZRS van de primaire server. Vanwege de synchronisatiereplicatietechnologie die wordt gebruikt in ZRS storage, kunt u een latentie van 5-10 procent verwachten voor schrijfbewerkingen en doorvoeringen van toepassingen.

De primaire databaseserver maakt automatisch een back-up van zowel momentopnamen als logboekback-ups op zone-redundante storage.

Architectuur voor lokaal-redundante hoge beschikbaarheid (HA)

Wanneer u een server met lokaal redundante ha implementeert, maakt u twee servers in dezelfde zone:

  • Een primaire server
  • Een stand-byreplicaserver met dezelfde configuratie als de primaire server (rekenlaag, rekenkracht, storage grootte en netwerkconfiguratie)

Diagram van beschikbaarheidszone.

De stand-byserver biedt infrastructuurredundantie met behulp van een afzonderlijke virtuele machine (compute). Deze redundantie vermindert de failovertijd en netwerklatentie tussen de toepassing en de databaseserver vanwege colocatie.

De gegevens en logboekbestanden worden gehost in lokaal redundante storage (LRS). De stand-byserver leest en afspeelt de logboekbestanden van het storage-account van de primaire server, dat wordt beveiligd door replicatie op storage niveau.

Als er een failover optreedt:

  • De stand-byreplica wordt geactiveerd.
  • De binaire logboekbestanden van de primaire server blijven van toepassing op de stand-byserver om deze online te brengen naar de laatste doorgevoerde transactie op de primaire server.

Logboeken in LRS zijn toegankelijk, zelfs wanneer de primaire server niet beschikbaar is. Deze beschikbaarheid helpt ervoor te zorgen dat er geen gegevens verloren gaan. Nadat de stand-byreplica is geactiveerd en binaire logboeken zijn toegepast, neemt de huidige stand-byreplica de rol van de primaire server. DNS wordt bijgewerkt om verbindingen om te leiden naar de nieuwe primaire server wanneer de client opnieuw verbinding maakt. De failover is volledig transparant vanuit de clienttoepassing en vereist geen actie van u. De ha-oplossing brengt vervolgens de oude primaire server indien mogelijk terug en plaatst deze als stand-by.

De naam van de databaseserver verbindt toepassingen met de primaire server. Informatie over standby-replica's wordt niet beschikbaar gesteld voor directe toegang. Doorvoeringen en schrijfbewerkingen worden bevestigd nadat de logboekbestanden zijn leeggemaakt op de LRS van de primaire server. Omdat de primaire replica en de stand-byreplica zich in dezelfde zone bevinden, is er minder replicatievertraging en lagere latentie tussen de toepassingsserver en de databaseserver. De lokaal-redundante configuratie biedt geen hoge beschikbaarheid wanneer afhankelijke infrastructuren uitvallen van de specifieke beschikbaarheidszone. Er is een onderbreking totdat alle afhankelijke diensten weer online zijn voor die beschikbaarheidszone.

De primaire databaseserver maakt automatisch een back-up van zowel momentopnamen als logboekback-ups naar lokaal redundante storage.

Notitie

Voor zowel zone-redundante als lokale redundante ha:

  • Als er een fout optreedt, is de tijd die nodig is om de rol van primaire replica over te nemen, afhankelijk van de tijd die nodig is om het binaire logboek van het primaire storage account opnieuw af te spelen naar de stand-by. Als u de failovertijd wilt verminderen, gebruikt u primaire sleutels voor alle tabellen. Failovertijden duren doorgaans tussen 60 en 120 seconden.
  • De stand-byserver is niet beschikbaar voor lees- of schrijfbewerkingen. Het is een passieve stand-by om snelle failover mogelijk te maken.
  • Gebruik altijd een FQDN (Fully Qualified Domain Name) om verbinding te maken met uw primaire server. Vermijd het gebruik van een IP-adres om verbinding te maken. Als er een failover optreedt, kan een DNS A-record veranderen nadat de primaire en stand-byserverfuncties zijn gewijzigd. Deze wijziging voorkomt dat de toepassing verbinding maakt met de nieuwe primaire server als er een IP-adres wordt gebruikt in de connection string.

Migreren van een bestaande server naar een zone-redundante server

Als u uw Azure Database for MySQL server oorspronkelijk hebt ingericht als een niet-HA-server, kunt u deze inschakelen voor lokaal redundante HA-architectuur. Als u deze echter wilt inschakelen voor zone-redundante HA-architectuur, moet u een nieuwe server maken met de gewenste configuratie en naar deze server migreren door de volgende stappen uit te voeren:

  1. Maak een nieuwe server waarvoor zone-redundante hoge beschikbaarheid is ingeschakeld door de instructies voor het implementatieprogramma van uw voorkeur te volgen:

  2. Migreer uw workload naar de nieuwe server door een van deze benaderingen te volgen. Afhankelijk van de migratiebenadering is er mogelijk downtime vereist.

    • Methoden voor offlinemigratie: Als uw toepassing uitvaltijd kan bieden, zijn offlinemigraties altijd de voorkeurskeuze, omdat ze eenvoudig en eenvoudig kunnen worden uitgevoerd. Met een offlinemigratie wordt de bronserver offline gehaald en worden er een dump en herstel van de databases uitgevoerd op de doelserver. Voor deze optie is de meeste downtime vereist. De duur van de downtime wordt bepaald door de tijd die nodig is om het herstel uit te voeren op de doelserver.

      • Data Migration Service (DMS): Zie hoe u DMS kunt gebruiken door offline te migreren van MySQL naar Azure Database voor MySQL met behulp van DMS via het Azure-portaal.

        Hoewel in de zelfstudie stappen worden beschreven voor het migreren van een on-premises MySQL-server naar Azure Database for MySQL, kunt u dezelfde procedure gebruiken voor het migreren van gegevens van de ene Azure Database for MySQL-server die geen ondersteuning biedt voor beschikbaarheidszones naar een andere server die ondersteuning biedt voor beschikbaarheidszones.

      • Opensource-hulpprogramma's: U kunt offline migreren met behulp van opensource-hulpprogramma's zoals MySQL Workbench, mydumper/myloader of mysqldump om een back-up van de database te maken en te herstellen. Zie Options voor het migreren van Azure Database for MySQL - Enkele server naar flexibele server voor meer informatie over het gebruik van deze hulpprogramma's. Hoewel in de zelfstudie stappen worden beschreven voor het migreren van Azure MySQL Single Server naar Flexible Server, kunt u dezelfde procedure gebruiken voor het migreren van gegevens van de ene Azure Database for MySQL Flexibele server die geen ondersteuning biedt voor beschikbaarheidszones naar een andere die beschikbaarheidszones ondersteunt.

    • Benaderingen voor onlinemigratie: Onlinemigraties minimaliseren de downtime van toepassingen. De bronserver staat updates toe en de migratieoplossing repliceert de lopende wijzigingen tussen de bron- en doelserver, samen met de eerste dump en herstel op het doel. Deze benaderingen zijn echter complexer om te implementeren dan een offlinemigratie.

      • Data Migration Service (DMS): Zie Migreer van MySQL naar Azure Database voor MySQL online met behulp van DMS via de Azure Portal voor meer informatie over het gebruik van DMS.

        Hoewel in de zelfstudie stappen worden beschreven voor het migreren van een on-premises MySQL-server naar Azure Database for MySQL, kunt u dezelfde procedure gebruiken voor het migreren van gegevens van de ene Azure Database for MySQL-server die geen ondersteuning biedt voor beschikbaarheidszones naar een andere server die ondersteuning biedt voor beschikbaarheidszones.

      • Opensource-hulpprogramma's: U kunt een combinatie van opensource-hulpprogramma's gebruiken, zoals mydumper/myloader , samen met replicatie van gegevens.

Failoverproces

Tijdens het failoverproces in Azure Database for MySQL schakelt het systeem automatisch over van de primaire server naar de stand-byreplica. Deze switch zorgt voor continuïteit en minimaliseert downtime. Wanneer het systeem een fout detecteert, promoveert het de standby-replica als nieuwe primaire server. Het systeem past de binaire logboekbestanden van de oorspronkelijke primaire server toe op de stand-byreplica. Dit proces synchroniseert de stand-byreplica met de laatste doorgevoerde transactie en zorgt ervoor dat er geen gegevens verloren gaan. Deze naadloze overgang helpt hoge beschikbaarheid en betrouwbaarheid van de databaseservice te behouden.

Notitie

Om de afhankelijkheid van failovertijd op DNS-caching te verminderen, zullen vanaf oktober 2025 alle nieuwe high availability servers, die worden gemaakt met openbare toegang of private link, de nieuwe architectuur aannemen met een dedicatede SLB voor elke high availability server. Door het MySQL-gegevensverkeerspad te beheren, elimineert SLB de noodzaak van DNS-wijzigingen tijdens de failover en verbetert de failoverprestaties aanzienlijk. Hiermee wordt verkeer omgeleid naar het huidige primaire exemplaar tijdens een failover met behulp van taakverdelingsregels. Bestaande servers met openbare toegang ofwel privékoppeling worden om de impact te minimaliseren geleidelijk gemigreerd. Klanten die de voorkeur geven aan vroege migratie, kunnen hoge beschikbaarheid uitschakelen en opnieuw inschakelen. Deze functie wordt niet ondersteund voor servers die gebruikmaken van privé-access met VNet-integratie.

Gepland: geforceerde failover

Met Azure Database for MySQL flexibele server gedwongen failover kunt u handmatig een failover initiëren. Met deze mogelijkheid kunt u de functionaliteit testen met uw toepassingsscenario's en kunt u zich voorbereiden op storingen.

Een geforceerde failover triggert een evenement waarbij de stand-by-replica de primaire server wordt door dezelfde databaseservernaam te gebruiken en de DNS-record bij te werken. De oorspronkelijke primaire server wordt opnieuw opgestart en schakelt over naar de stand-byreplica. Clientverbindingen verbreken de verbinding en moeten opnieuw verbinding maken om hun bewerkingen te hervatten.

De totale failovertijd is afhankelijk van de huidige workload en het laatste controlepunt. Over het algemeen duurt het tussen de 60 en 120 seconden.

Notitie

Er wordt een Azure Resource Health gebeurtenis gegenereerd tijdens een geplande failover. De gebeurtenis vertegenwoordigt de failovertijd waarin de server niet beschikbaar is. U kunt de geactiveerde gebeurtenissen zien wanneer deze zijn geselecteerd op Resource Health in het linkerdeelvenster. De status vertegenwoordigt door de gebruiker geïnitieerde of handmatige failover als Niet beschikbaar en gelabeld als Gepland. Een failoverbewerking is bijvoorbeeld geactiveerd door een geautoriseerde gebruiker (gepland). Als uw resource gedurende een langere periode in deze status blijft, opent u een supportticket en helpen we u.

Niet-gepland: automatische failover

Niet-geplande service-downtime kan optreden vanwege softwarefouten of infrastructuurfouten, zoals reken-, netwerk- of storage fouten. Stroomstoringen kunnen ook van invloed zijn op de beschikbaarheid van de database. Als de database niet meer beschikbaar is, stopt de replicatie naar de stand-byreplica en wordt de stand-byreplica de primaire database. DNS-updates vinden plaats en clients maken opnieuw verbinding met de databaseserver en hervatten hun bewerkingen.

De totale failovertijd is meestal tussen 60 en 120 seconden. Afhankelijk van de activiteit op de primaire databaseserver op het moment van de failover (zoals grote transacties en hersteltijd), kan de failover echter langer duren.

Notitie

Een niet-geplande failover genereert een Resource Health gebeurtenis. De gebeurtenis vertegenwoordigt de failovertijd wanneer de server niet beschikbaar is. U kunt de geactiveerde gebeurtenissen zien wanneer u Resource Health selecteert in het linkerdeelvenster. Automatische failover toont de status Niet beschikbaar en is gelabeld als Niet-gepland.

Bijvoorbeeld: Niet beschikbaar: Er is automatisch een failoverbewerking geactiveerd (ongepland). Als uw resource lang in deze status blijft, opent u een supportticket en helpen we u.

Hoe automatische failoverdetectie werkt op servers met hoge beschikbaarheid

De primaire server en de secundaire server hebben elk twee netwerkeindpunten:

  • Klanteindpunt: Klanten maken verbinding met en voeren query's uit op het exemplaar met behulp van dit eindpunt.
  • Beheereindpunt: intern gebruikt voor servicecommunicatie naar beheeronderdelen en om verbinding te maken met back-end-storage.

Het onderdeel statuscontrole voert continu de volgende controles uit:

  • De monitor pingt het beheernetwerkeindpunt van het knooppunt. Als deze controle twee keer achter elkaar mislukt, wordt er een automatische failoverbewerking geactiveerd. Deze statuscontrole behandelt scenario's zoals knooppunten die niet beschikbaar zijn of niet reageren vanwege problemen met het besturingssysteem, netwerkproblemen tussen beheeronderdelen en knooppunten en vergelijkbare problemen.
  • De monitor voert een eenvoudige query uit op het exemplaar. Als de query's niet worden uitgevoerd, treedt automatische failover in werking. Deze statuscontrole behandelt scenario's zoals MySQL-daemon-crashes, stops of vastlopen, en back-end storage problemen, en vergelijkbare problemen.

Notitie

De gezondheidstest bewaakt geen netwerkproblemen tussen de applicatie en het netwerk-eindpunt van de klant (privé/openbaar toegang). Deze problemen kunnen optreden in het netwerkpad, op het eindpunt of in DNS-problemen aan de clientzijde. nl-NL: Als u privétoegang gebruikt, moet u ervoor zorgen dat de NSG-regels voor het virtuele netwerk de communicatie met het eindpunt van het klantnetwerk van het exemplaar niet blokkeren op poort 3306. Zorg ervoor dat voor openbare access de firewallregels zijn ingesteld en dat netwerkverkeer is toegestaan op poort 3306 (als het netwerkpad andere firewalls heeft). U moet ook zorgen voor DNS-omzetting aan de clienttoepassingszijde.

Hoge beschikbaarheid monitoren

Als u de configuratiestatus van de server met hoge beschikbaarheid wilt controleren, gebruikt u de status van hoge beschikbaarheid in het deelvenster hoge beschikbaarheid van de server in de portal.

Status Beschrijving
NotEnabled Hoge beschikbaarheid is niet ingeschakeld.
ReplicatingData De stand-byserver wordt gesynchroniseerd met de primaire server tijdens het inrichten van servers met hoge beschikbaarheid of wanneer u de optie voor hoge beschikbaarheid inschakelt.
Failover De databaseserver voert een failover uit van de primaire server naar de stand-by.
Gezond Optie voor hoge beschikbaarheid is ingeschakeld.
RemovingStandby Het verwijderingsproces wordt uitgevoerd wanneer u de optie voor hoge beschikbaarheid uitschakelt.

Gebruik de volgende metrische gegevens om de status van de server met hoge beschikbaarheid te bewaken.

Weergavenaam voor metrische gegevens Metrische gegevens Eenheid Beschrijving
Hoge IO beschikbaarheidsstatus ha_io_running Provincie IO HA-status geeft de status van HA-replicatie weer. De metriekwaarde is 1 als de I/O-thread wordt uitgevoerd en 0 als dat niet het geval is.
HA SQL-status ha_sql_running Provincie HA SQL-status toont de status van replicatie met hoge beschikbaarheid. De waarde van de metriek is 1 als de SQL-thread wordt uitgevoerd en 0 anders.
HA-replicatievertraging replication_lag Seconden Replicatievertraging is het aantal seconden dat de standby-server achterloopt bij het opnieuw afspelen van de transacties die zijn ontvangen op de primaire server.

Beperkingen

Houd rekening met de volgende overwegingen wanneer u hoge beschikbaarheid gebruikt:

  • U kunt zone-redundante hoge beschikbaarheid alleen configureren tijdens het maken van de server.

  • De burstable compute-laag biedt geen ondersteuning voor hoge beschikbaarheid.

  • Als u de primaire databaseserver opnieuw opstart om statische parameterwijzigingen toe te passen, wordt ook de stand-byreplica opnieuw opgestart.

  • De oplossing schakelt de GTID-modus in omdat deze GTID gebruikt. Controleer of uw workload beperkingen of limitaties heeft voor replicatie met GTID's.

Notitie

Storage automatisch groeien is standaard ingeschakeld voor een geconfigureerde server met hoge beschikbaarheid en kan niet worden uitgeschakeld.

Bekende problemen

Azure Database for MySQL Flexibele server maakt gebruik van systeemeigen MySQL-replicatie op de back-end. Er bestaat een bekend probleem in mySQL Community Edition 8.0 en hoger dat replicatie kan verbreken bij het uitvoeren van een multitabele DELETE-bewerking die afhankelijk is van beperkingen voor refererende sleutels met ON DELETE CASCADE. Dit probleem wordt bijgehouden als MySQL-bug 102586. Als u Hoge beschikbaarheid inschakelt op Azure Database for MySQL Flexible Server, moet u vermijden om trapsgewijs verwijderen met vreemde sleutels te gebruiken, omdat dit patroon tot replicatiefouten kan leiden en van invloed kan zijn op de beschikbaarheid van de server.

Gezondheidscontrole

Wanneer u hoge beschikbaarheid (HA) configureert voor Azure Database for MySQL, speelt Health Check een cruciale rol bij het onderhouden van de betrouwbaarheid en prestaties van uw database. Deze controles controleren continu de status en gezondheid van zowel de primaire als de standbyreplica's, zodat ze eventuele problemen onmiddellijk detecteren. Door verschillende metrische gegevens bij te houden, zoals reactietijd van de server, replicatievertraging en resourcegebruik, zorgt Health Check ervoor dat failoverprocessen naadloos kunnen worden uitgevoerd, waardoor downtime wordt geminimaliseerd en gegevensverlies wordt voorkomen. De goed geconfigureerde statuscontrole is essentieel voor het bereiken van het gewenste beschikbaarheidsniveau en de tolerantie in uw database-installatie.

Gezondheidsmonitoring

U kunt de status van uw ha-instellingen bewaken via de Azure portal. Belangrijke metrische gegevens die moeten worden waargenomen, zijn:

  • Reactiesnelheid van de server: geeft aan of de primaire server bereikbaar is.
  • Replicatievertraging: meet de vertraging tussen de primaire en stand-byreplica's, waardoor gegevensconsistentie wordt gegarandeerd.
  • Resourcegebruik: bewaakt cpu-, geheugen- en storage gebruik om knelpunten te voorkomen.

Betrouwbaarheid en tolerantie

Zie Betrouwbaarheid in Azure Database for MySQL voor een uitgebreid overzicht van betrouwbaarheid, waaronder tijdelijke foutafhandeling, tolerantie voor beschikbaarheidszones, herstel na noodgevallen tussen regio's met leesreplica's, back-up en herstel en serviceonderhoud. Zie Betrouwbaarheid in Azure Database for MySQL.

Gerelateerde inhoud

  • Last updated on