Delen via

Hoge beschikbaarheid in Azure Database for MySQL

Met Azure Database for MySQL Flexible 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-byreplica in en beheert deze. U betaalt voor de ingerichte rekenkracht en opslag voor zowel de primaire als de secundaire replica' s. Er zijn twee architectuurmodellen met hoge beschikbaarheid beschikbaar:

  • Zone-redundante hoge beschikbaarheid. Deze optie biedt volledige isolatie en redundantie van infrastructuur in meerdere beschikbaarheidszones. Het biedt het hoogste beschikbaarheidsniveau, maar hiervoor moet u toepassingsredundantie tussen zones configureren. Kies zone-redundante ha 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 u toepassingsredundantie tussen zones hoeft te configureren. Kies voor lokaal-redundante hoge beschikbaarheid als u het hoogste niveau van beschikbaarheid binnen één beschikbaarheidszone wilt bereiken, met de laagste netwerklatentie. Lokale redundante ha 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-byreplicaserver in een andere beschikbaarheidszone van dezelfde Azure-regio. De stand-byreplicaserver heeft dezelfde configuratie als de primaire server, waaronder de rekenlaag, de rekengrootte, de opslaggrootte en de netwerkconfiguratie.

U kunt de beschikbaarheidszone kiezen voor zowel de primaire server als de stand-byreplica. Het plaatsen van de stand-bydatabaseservers en stand-bytoepassingen in dezelfde zone vermindert de latentie. Het helpt u ook bij het voorbereiden van situaties met herstel na noodgevallen en scenario's met 'zone down'.

Diagram met de architectuur voor zone-redundante hoge beschikbaarheid.

De gegevens en logboekbestanden worden gehost in zone-redundante opslag (ZRS). De stand-byserver leest en afspeelt de logboekbestanden continu vanuit het opslagaccount van de primaire server, dat replicatie op opslagniveau 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-byreplica-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-opslag, kunt u 5-10 procent hogere latentie verwachten voor schrijf- en doorvoerbewerkingen van toepassingen.

Automatische back-ups, zowel momentopnamen als logboekback-ups, worden uitgevoerd op zone-redundante opslag vanaf de primaire databaseserver.

Architectuur voor lokaal-redundante hoge beschikbaarheid (HA)

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

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

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

Diagram met de architectuur voor lokaal redundante hoge beschikbaarheid.

De gegevens en logboekbestanden worden gehost in lokaal redundante opslag (LRS). De stand-byserver leest en afspeelt continu de logboekbestanden uit het opslagaccount van de primaire server, dat wordt beveiligd door replicatie op opslagniveau.

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 stand-byreplica's wordt niet weergegeven 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 opstelling biedt geen hoge beschikbaarheid wanneer afhankelijke infrastructuren uitvallen in de specifieke beschikbaarheidszone. Er is downtime totdat alle afhankelijke services weer online zijn voor die beschikbaarheidszone.

Automatische back-ups, zowel momentopnamen als logboekback-ups, worden uitgevoerd op lokaal redundante opslag vanaf de primaire databaseserver.

Notitie

Voor zowel zone-redundante als lokaal redundante ha:

  • Als er een fout optreedt, is de tijd die nodig is voor de stand-byreplica om de rol van primaire replica over te nemen, afhankelijk van de tijd die nodig is om het binaire logboek van het primaire opslagaccount opnieuw af te spelen op 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 verbindingsreeks.

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, bevordert het de stand-byreplica om de nieuwe primaire server te worden. 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 overstaptijd op DNS-caching te verminderen, zullen vanaf oktober 2025 alle nieuwe HA-servers die zijn gemaakt met openbare toegang of private link, de nieuwe architectuur aannemen met een toegewezen SLB voor elke HA-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 of privékoppeling worden geleidelijk gemigreerd om de impact te minimaliseren. Klanten die de voorkeur geven aan vroege migratie, kunnen HA uitschakelen en weer inschakelen. Deze functie wordt niet ondersteund voor servers die gebruikmaken van privétoegang met VNet-integratie.

Gepland: geforceerde failover

Met geforceerde failover van Azure Database for MySQL Flexible Server kunt u handmatig een failover afdwingen. Met deze mogelijkheid kunt u de functionaliteit testen met uw toepassingsscenario's en kunt u zich voorbereiden op storingen.

Geforceerde failover activeert een failover die de stand-byreplica activeert om de primaire server met dezelfde databaseservernaam te worden door 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 in Resource Health in het linkerdeelvenster. De status vertegenwoordigt door de gebruiker geïnitieerde of handmatige failover als Niet beschikbaar en gemarkeerd als Gepland. Voorbeeld: 'Er is een failoverbewerking geactiveerd door een geautoriseerde gebruiker (gepland)'. Als uw resource gedurende een langere periode in deze status blijft staan, opent u een ondersteuningsticket en helpen we u.

Niet-gepland: automatische failover

Niet-geplande service-downtime kan optreden vanwege softwarefouten of infrastructuurfouten, zoals reken-, netwerk- of opslagfouten. 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

Er wordt een Azure Resource Health-gebeurtenis gegenereerd tijdens een niet-geplande failover. 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: Er is automatisch een failoverbewerking geactiveerd (ongepland). Als uw resource lange tijd in deze status blijft, opent u een ondersteuningsticket 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-endopslag.

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, worden automatische failovertriggers geactiveerd. Deze statuscontrole behandelt scenario's zoals MySQL-daemon-crashes, stops of vastlopen, en problemen met back-endopslag en soortgelijke problemen.

Notitie

De statuscontrole bewaakt geen netwerkproblemen tussen de toepassing en het eindpunt van het klantnetwerk (privé-/openbare toegang). Deze problemen kunnen optreden in het netwerkpad, op het eindpunt of in DNS-problemen aan de clientzijde. 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 op poort 3306 niet blokkeren. Voor openbare toegang moet u ervoor zorgen dat 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 bewaken

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.
Standby verwijderen 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 Hoge beschikbaarheidsstatus geeft de status van ha-replicatie weer. De metrische waarde is 1 als de I/O-thread wordt uitgevoerd en 0 als dat niet het resultaat is.
HOGE SQL-status ha_sql_running Provincie Hoge SQL-status toont de status van replicatie met hoge beschikbaarheid. De metrische waarde is 1 als de SQL-thread wordt uitgevoerd en 0 als dat niet het resultaat is.
Ha-replicatievertraging replication_lag Seconden Replicatievertraging is het aantal seconden dat de stand-by zich bevindt 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 heeft voor replicatie met GTID's.

Notitie

Automatische groei van opslag is standaard ingeschakeld voor een geconfigureerde server met hoge beschikbaarheid en kan niet worden uitgeschakeld.

Statuscontroles

Wanneer u hoge beschikbaarheid (HA) configureert voor Azure Database for MySQL, spelen statuscontroles een cruciale rol bij het onderhouden van de betrouwbaarheid en prestaties van uw database. Deze controles controleren continu de status en status van zowel de primaire als stand-byreplica's, zodat ze eventuele problemen onmiddellijk detecteren. Door verschillende metrische gegevens bij te houden, zoals reactietijd van servers, replicatievertraging en resourcegebruik, helpen statuscontroles ervoor te zorgen dat failoverprocessen naadloos kunnen worden uitgevoerd, waardoor downtime wordt geminimaliseerd en gegevensverlies wordt voorkomen. Goed geconfigureerde statuscontroles zijn essentieel voor het bereiken van het gewenste beschikbaarheids- en tolerantieniveau in uw database-installatie.

Status bewaken

U kunt de status van uw hoge beschikbaarheid controleren via 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 het CPU-, geheugen- en opslaggebruik om knelpunten te voorkomen.

Gerelateerde inhoud

  • Last updated on