Share via

Leesreplica's in Azure Database for MySQL

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - enkele server

Belangrijk

Azure Database for MySQL enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan een upgrade uit te voeren naar een flexibele Azure Database for MySQL-server. Zie Wat gebeurt er met Azure Database for MySQL Enkele server voor meer informatie over migreren naar Azure Database for MySQL Flexibele server ?

Met de functie leesreplica kunt u gegevens van een Azure Database for MySQL-server repliceren naar een alleen-lezen server. U kunt maximaal vijf replica's van de bronserver repliceren. Replica's worden asynchroon bijgewerkt met behulp van de systeemeigen, op de positie van het binlog-bestand (binair logboekbestand) gebaseerde replicatietechnologie van het MySQL-systeem. Zie het overzicht van de replicatie van binlog-binlog in MySQL voor meer informatie over binlog-replicatie.

Replica's zijn nieuwe servers die u beheert, vergelijkbaar met gewone Azure Database for MySQL-servers. Voor elke leesreplica wordt u gefactureerd voor de ingerichte rekenkracht in vCores en opslag in GB/maand.

Raadpleeg de MySQL-replicatiedocumentatie voor meer informatie over MySQL-replicatiefuncties en -problemen.

Notitie

Dit artikel bevat verwijzingen naar de term slave, een term die Microsoft niet meer gebruikt. Zodra de term uit de software wordt verwijderd, verwijderen we deze uit dit artikel.

Wanneer u een leesreplica moet gebruiken

De leesreplicafunctie helpt de prestaties en schaal van leesintensieve werkbelastingen verbeteren. Leesworkloads kunnen worden geïsoleerd voor de replica's, terwijl schrijfworkloads naar de bron kunnen worden omgeleid.

Een veelvoorkomend scenario is om BI en analytische werkbelastingen de leesreplica's te laten gebruiken als de gegevensbron voor rapportage.

Omdat replica's alleen-lezen zijn, verminderen ze niet rechtstreeks de belasting van schrijfcapaciteit voor de bron. Deze functie is niet gericht op schrijfintensieve werkbelastingen.

De functie leesreplica maakt gebruik van asynchrone MySQL-replicatie. De functie is niet bedoeld voor synchrone replicatiescenario's. Er is een meetbare vertraging tussen de bron en de replica. De gegevens op de replica worden uiteindelijk consistent met de gegevens in de bron. Gebruik deze functie voor workloads die deze vertraging aan kunnen.

Replicatie in meerdere regio's

U kunt een leesreplica maken in een andere regio dan uw bronserver. Replicatie tussen regio's kan handig zijn voor scenario's als het plannen van herstel na noodgeval of het dichter bij uw gebruikers brengen van gegevens.

U kunt een bronserver hebben in elke Azure Database for MySQL-regio. Een bronserver kan een replica hebben in de gekoppelde regio of de universele replicaregio's. In de volgende afbeelding ziet u welke replicaregio's beschikbaar zijn, afhankelijk van uw bronregio.

Universele replicaregio's

U kunt een leesreplica maken in een van de volgende regio's, ongeacht waar uw bronserver zich bevindt. De ondersteunde universele replicaregio's zijn onder andere:

Regio Beschikbaarheid van replica's
Australië - oost ✔️
Australië - zuidoost ✔️
Brazilië - zuid ✔️
Canada - midden ✔️
Canada - oost ✔️
Central US ✔️
VS - oost ✔️
VS - oost 2 ✔️
Azië - oost ✔️
Japan East ✔️
Japan - west ✔️
Korea - centraal ✔️
Korea - zuid ✔️
Europa - noord ✔️
VS - noord-centraal ✔️
VS - zuid-centraal ✔️
Azië - zuidoost ✔️
Zwitserland - noord ✔️
VK - zuid ✔️
Verenigd Koninkrijk West ✔️
VS - west-centraal ✔️
VS - west ✔️
VS - west 2 ✔️
Europa -west ✔️
India - centraal* ✔️
Frankrijk - centraal* ✔️
UAE - noord* ✔️
Zuid-Afrika - noord* ✔️

Notitie

*Regio's waarin Azure Database for MySQL opslag voor algemeen gebruik v2 heeft in openbare preview
*Voor deze Azure-regio's hebt u de mogelijkheid om een server te maken in opslag voor algemeen gebruik v1 en v2. Voor de servers die zijn gemaakt met opslag voor algemeen gebruik v2 in openbare preview, kunt u alleen replicaserver maken in de Azure-regio's die ondersteuning bieden voor opslag voor algemeen gebruik v2.

Gekoppelde regio's

Naast de universele replicaregio's kunt u een leesreplica maken in de gekoppelde Azure-regio van uw bronserver. Als u het paar van uw regio niet weet, vindt u meer informatie in het artikel gekoppelde Azure-regio's.

Als u replica's voor meerdere regio's gebruikt voor het plannen van herstel na noodgevallen, raden we u aan om de replica te maken in de gekoppelde regio in plaats van een van de andere regio's. Gekoppelde regio's voorkomen gelijktijdige updates en prioriteren fysieke isolatie en gegevenslocatie.

Er zijn echter beperkingen om rekening mee te houden:

  • Regionale beschikbaarheid: Azure Database for MySQL is beschikbaar in Frankrijk - centraal, UAE - noord en Duitsland - centraal. De gekoppelde regio's zijn echter niet beschikbaar.

  • Unidirectionele paren: sommige Azure-regio's worden slechts in één richting gekoppeld. Deze regio's omvatten India - west, Brazilië - zuid en US Gov Virginia. Dit betekent dat een bronserver in India - west een replica kan maken in India - zuid. Een bronserver in India - zuid kan echter geen replica maken in India - west. Dit komt doordat de secundaire regio van India - west India is, maar de secundaire regio van Zuid-India is niet India - west.

Replica's maken

Belangrijk

  • De functie leesreplica is alleen beschikbaar voor Azure Database for MySQL-servers in de prijscategorieën Algemeen gebruik of Geoptimaliseerd voor geheugen. Zorg ervoor dat de bronserver zich in een van deze prijscategorieën bevindt.
  • Als uw bronserver geen bestaande replicaservers heeft, moet de bronserver mogelijk opnieuw worden opgestart om zich voor te bereiden op replicatie, afhankelijk van de gebruikte opslag (v1/v2). Overweeg opnieuw opstarten van de server en voer deze bewerking uit tijdens daluren. Zie Het opnieuw opstarten van de bronserver voor meer informatie.

Wanneer u de werkstroom voor het maken van replica's start, wordt er een lege Azure Database for MySQL-server gemaakt. De nieuwe server wordt gevuld met de gegevens die zich op de bronserver bevinden. De aanmaaktijd is afhankelijk van de hoeveelheid gegevens op de bron en de tijd sinds de vorige wekelijkse volledige back-up. De tijd kan variëren van enkele minuten tot enkele uren. De replicaserver wordt altijd gemaakt in dezelfde resourcegroep en hetzelfde abonnement als de bronserver. Als u een replicaserver wilt maken naar een andere resourcegroep of een ander abonnement, kunt u de replicaserver na het maken verplaatsen.

Elke replica is ingeschakeld voor automatisch vergroten van opslag. Met de functie voor automatisch vergroten kan de replica de gegevens bijhouden die ernaar worden gerepliceerd en wordt een onderbreking van de replicatie voorkomen die wordt veroorzaakt door storingen in de opslag.

Meer informatie over het maken van een leesreplica in Azure Portal.

Verbinding maken met een replica

Bij het maken neemt een replica de firewallregels van de bronserver over. Daarna zijn deze regels onafhankelijk van de bronserver.

De replica neemt het beheerdersaccount over van de bronserver. Alle gebruikersaccounts op de bronserver worden gerepliceerd naar de leesreplica's. U kunt alleen verbinding maken met een leesreplica met behulp van de gebruikersaccounts die beschikbaar zijn op de bronserver.

U kunt verbinding maken met de replica met behulp van de hostnaam en een geldig gebruikersaccount, net als op een gewone Azure Database for MySQL-server. Voor een server met de naam myreplica met de gebruikersnaam myadmin van de beheerder kunt u verbinding maken met de replica met behulp van de mysql CLI:

mysql -h myreplica.mysql.database.azure.com -u myadmin@myreplica -p

Voer bij de prompt het wachtwoord voor het gebruikersaccount in.

Replicatie bewaken

Azure Database for MySQL biedt de replicatievertraging in seconden metrische gegevens in Azure Monitor. Deze metrische waarde is alleen beschikbaar voor replica's. Deze metrische waarde wordt berekend met behulp van de seconds_behind_master metrische waarde die beschikbaar is in de opdracht van SHOW SLAVE STATUS MySQL. Stel een waarschuwing in om u te informeren wanneer de replicatievertraging een waarde bereikt die niet acceptabel is voor uw workload.

Als u een verhoogde replicatievertraging ziet, raadpleegt u de latentie van replicatie oplossen om mogelijke oorzaken op te lossen en te begrijpen.

Replicatie stoppen

U kunt de replicatie tussen een bron en een replica stoppen. Nadat de replicatie tussen een bronserver en een leesreplica is gestopt, wordt de replica een zelfstandige server. De gegevens op de zelfstandige server zijn de gegevens die beschikbaar waren op de replica op het moment dat de replicatieopdracht stoppen werd gestart. De zelfstandige server haalt de bronserver niet op.

Wanneer u ervoor kiest om de replicatie naar een replica te stoppen, gaan alle koppelingen naar de vorige bron en andere replica's verloren. Er is geen automatische failover tussen een bron en de replica.

Belangrijk

De zelfstandige server kan niet opnieuw in een replica worden gemaakt. Voordat u de replicatie op een leesreplica stopt, moet u ervoor zorgen dat de replica alle gegevens bevat die u nodig hebt.

Meer informatie over het stoppen van replicatie naar een replica.

Failover

Er is geen automatische failover tussen bron- en replicaservers.

Omdat replicatie asynchroon is, is er vertraging tussen de bron en de replica. De hoeveelheid vertraging kan worden beïnvloed door veel factoren, zoals hoe zwaar de werkbelasting op de bronserver is en de latentie tussen datacenters. In de meeste gevallen varieert replicavertraging tussen enkele seconden en een paar minuten. U kunt de werkelijke replicatievertraging bijhouden met behulp van de metrische replicavertraging, die beschikbaar is voor elke replica. Deze metrische waarde toont de tijd sinds de laatste opnieuw afgespeelde transactie. U wordt aangeraden te bepalen wat uw gemiddelde vertraging is door de replicavertraging gedurende een bepaalde periode te observeren. U kunt een waarschuwing instellen voor replicavertraging, zodat u actie kunt ondernemen als deze buiten het verwachte bereik valt.

Tip

Als u een failover naar de replica uitvoert, geeft de vertraging op het moment dat u de replica loskoppelt van de bron aan hoeveel gegevens verloren gaan.

Nadat u hebt besloten dat u een failover naar een replica wilt uitvoeren:

  1. Replicatie naar de replica stoppen
    Deze stap is nodig om de replicaserver schrijfbewerkingen te laten accepteren. Als onderdeel van dit proces wordt de replicaserver losgekoppeld van de bron. Nadat u de replicatie hebt gestart, duurt het doorgaans ongeveer 2 minuten voordat het back-endproces is voltooid. Zie de sectie stopreplicatie van dit artikel om inzicht te krijgen in de gevolgen van deze actie.

  2. Uw toepassing naar de (voormalige) replica laten wijzen
    Elke server heeft een unieke verbindingsreeks. Werk uw toepassing bij zodat deze verwijst naar de (voormalige) replica in plaats van de bron.

Nadat uw toepassing lees- en schrijfbewerkingen heeft verwerkt, hebt u de failover voltooid. De hoeveelheid downtime die uw toepassingservaringen hebben, is afhankelijk van wanneer u een probleem detecteert en stap 1 en 2 uitvoert die eerder zijn vermeld.

Globale transactie-id (GTID)

Global Transaction Identifier (GTID) is een unieke id die wordt gemaakt met elke doorgevoerde transactie op een bronserver en is standaard UIT in Azure Database for MySQL. GTID wordt ondersteund op versies 5.7 en 8.0 en alleen op servers die opslag ondersteunen tot 16 TB (Opslag voor algemeen gebruik v2). Raadpleeg de replicatie van MySQL met GTID-documentatie voor meer informatie over GTID en hoe deze wordt gebruikt in replicatie.

MySQL ondersteunt twee soorten transacties: GTID-transacties (geïdentificeerd met GTID) en anonieme transacties (geen GTID toegewezen)

De volgende serverparameters zijn beschikbaar voor het configureren van GTID:

Serverparameter Beschrijving Standaardwaarde Waarden
gtid_mode Geeft aan of GTID's worden gebruikt om transacties te identificeren. Wijzigingen tussen modi kunnen slechts één stap tegelijk worden uitgevoerd in oplopende volgorde (bijvoorbeeld OFF ->OFF_PERMISSIVEON_PERMISSIVE> - -)>ON OFF OFF: Zowel nieuwe transacties als replicatietransacties moeten anoniem zijn
OFF_PERMISSIVE: Nieuwe transacties zijn anoniem. Gerepliceerde transacties kunnen anonieme of GTID-transacties zijn.
ON_PERMISSIVE: Nieuwe transacties zijn GTID-transacties. Gerepliceerde transacties kunnen anonieme of GTID-transacties zijn.
ON: Zowel nieuwe als gerepliceerde transacties moeten GTID-transacties zijn.
enforce_gtid_consistency Dwingt GTID-consistentie af door alleen de instructies toe te staan die op een transactieveilige manier kunnen worden vastgelegd. Deze waarde moet worden ingesteld ON op voordat GTID-replicatie wordt ingeschakeld. OFF OFF: Alle transacties mogen GTID-consistentie schenden.
ON: Er is geen transactie toegestaan om GTID-consistentie te schenden.
WARN: alle transacties mogen gtID-consistentie schenden, maar er wordt een waarschuwing gegenereerd.

Notitie

  • Nadat GTID is ingeschakeld, kunt u deze niet meer uitschakelen. Als u GTID wilt uitschakelen, neemt u contact op met de ondersteuning.

  • Als u GTID's van de ene waarde naar de andere wilt wijzigen, kan slechts één stap tegelijk in oplopende volgorde van modi zijn. Als gtid_mode momenteel bijvoorbeeld is ingesteld op OFF_PERMISSIVE, is het mogelijk om over te schakelen naar ON_PERMISSIVE, maar niet naar AAN.

  • Als u de replicatie consistent wilt houden, kunt u deze niet bijwerken voor een hoofd-/replicaserver.

  • Aanbevolen om enforce_gtid_consistency in te stellen op AAN voordat u gtid_mode=ON kunt instellen

Als u GTID wilt inschakelen en het consistentiegedrag wilt configureren, werkt u de gtid_mode parameters en enforce_gtid_consistency serverparameters bij met behulp van Azure Portal, Azure CLI of PowerShell.

Als GTID is ingeschakeld op een bronserver (gtid_mode = AAN), hebben nieuw gemaakte replica's ook GTID ingeschakeld en wordt GTID-replicatie gebruikt. Om ervoor te zorgen dat de replicatie consistent is, gtid_mode kan deze niet worden gewijzigd zodra de hoofd- of replicaserver(s) is gemaakt met GTID ingeschakeld.

Overwegingen en beperkingen

Prijscategorieën

Leesreplica's zijn momenteel alleen beschikbaar in de prijscategorieën Algemeen gebruik en Geoptimaliseerd voor geheugen.

Notitie

De kosten voor het uitvoeren van de replicaserver zijn gebaseerd op de regio waar de replicaserver wordt uitgevoerd.

Bronserver opnieuw opstarten

Server met Opslag voor algemeen gebruik v1, de log_bin parameter is standaard UITGESCHAKELD. De waarde wordt ingeschakeld wanneer u de eerste leesreplica maakt. Als een bronserver geen bestaande leesreplica's heeft, wordt de bronserver eerst opnieuw opgestart om zich voor te bereiden op replicatie. Overweeg opnieuw opstarten van de server en voer deze bewerking uit tijdens daluren.

De bronserver met opslag voor algemeen gebruik v2 is log_bin standaard ingeschakeld en vereist geen herstart wanneer u een leesreplica toevoegt.

Nieuwe replica's

Er wordt een leesreplica gemaakt als een nieuwe Azure Database for MySQL-server. Een bestaande server kan niet worden gemaakt in een replica. U kunt geen replica van een andere leesreplica maken.

Replicaconfiguratie

Er wordt een replica gemaakt met dezelfde serverconfiguratie als de bron. Nadat een replica is gemaakt, kunnen verschillende instellingen onafhankelijk van de bronserver worden gewijzigd: compute-generatie, vCores, opslag en bewaarperiode voor back-ups. De prijscategorie kan ook onafhankelijk worden gewijzigd, behalve van of van de Basic-laag.

Belangrijk

Voordat een configuratie van een bronserver wordt bijgewerkt naar nieuwe waarden, moet u de configuratie van de replica bijwerken naar gelijke of hogere waarden. Met deze actie wordt ervoor gezorgd dat in de replica alle wijzigingen worden doorgevoerd die in de bronserver zijn aangebracht.

Firewallregels en parameterinstellingen worden overgenomen van de bronserver naar de replica wanneer de replica wordt gemaakt. Daarna zijn de regels van de replica onafhankelijk.

Gestopte replica's

Als u de replicatie tussen een bronserver en een leesreplica stopt, wordt de gestopte replica een zelfstandige server die zowel lees- als schrijfbewerkingen accepteert. De zelfstandige server kan niet opnieuw in een replica worden gemaakt.

Verwijderde bron- en zelfstandige servers

Wanneer een bronserver wordt verwijderd, wordt de replicatie gestopt naar alle leesreplica's. Deze replica's worden automatisch zelfstandige servers en kunnen zowel lees- als schrijfbewerkingen accepteren. De bronserver zelf wordt verwijderd.

Gebruikersaccounts

Gebruikers op de bronserver worden gerepliceerd naar de leesreplica's. U kunt alleen verbinding maken met een leesreplica met behulp van de gebruikersaccounts die beschikbaar zijn op de bronserver.

Serverparameters

Om problemen met de synchronisatie van gegevens en mogelijk verlies of beschadiging van gegevens te voorkomen, worden bepaalde serverparameters vergrendeld zodat ze niet kunnen worden bijgewerkt bij gebruik van replica's voor lezen.

De volgende serverparameters zijn vergrendeld op de bron- en replicaservers:

De event_scheduler parameter is vergrendeld op de replicaservers.

Als u een van de bovenstaande parameters op de bronserver wilt bijwerken, verwijdert u replicaservers, werkt u de parameterwaarde op de bron bij en maakt u replica's opnieuw.

GTID

GTID wordt ondersteund op:

  • MySQL-versies 5.7 en 8.0.
  • Servers die opslag ondersteunen tot 16 TB. Raadpleeg het artikel over de prijscategorie voor de volledige lijst met regio's die ondersteuning bieden voor 16 TB-opslag.

GTID is standaard UITGESCHAKELD. Nadat GTID is ingeschakeld, kunt u dit niet meer uitschakelen. Als u GTID wilt uitschakelen, neemt u contact op met de ondersteuning.

Als GTID is ingeschakeld op een bronserver, is in nieuwe replica's ook GTID ingeschakeld en wordt GTID-replicatie gebruikt. Als u de replicatie consistent wilt houden, kunt u de bron- of replicaserver(s) niet bijwerken gtid_mode .

Overige

  • Het maken van een replica van een replica wordt niet ondersteund.
  • In-memory tabellen kunnen ervoor zorgen dat replica's niet meer worden gesynchroniseerd. Dit is een beperking van de MySQL-replicatietechnologie. Lees meer in de MySQL-referentiedocumentatie voor meer informatie.
  • Zorg ervoor dat de bronservertabellen primaire sleutels hebben. Het ontbreken van primaire sleutels kan leiden tot replicatielatentie tussen de bron en replica's.
  • Bekijk de volledige lijst met mySQL-replicatiebeperkingen in de MySQL-documentatie

Volgende stappen