Replica's lezen in Azure Database for MySQL - Flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - Flexibele server

MySQL is een van de populaire database-engines voor het uitvoeren van webtoepassingen en mobiele toepassingen op het internet. Veel van onze klanten gebruiken MySQL voor hun online onderwijsservices, videostreamingservices, oplossingen voor digitale betalingen, e-commerceplatforms, gamingservices, nieuwsportalen en websites voor de overheid of gezondheidszorg. Deze services moeten kunnen presteren en schalen als het verkeer op de web- of mobiele toepassing toeneemt.

Aan de kant van toepassingen wordt de toepassing doorgaans ontwikkeld in Java of PHP en gemigreerd om te worden uitgevoerd op Azure Virtual Machine Scale Sets of Azure-app Services of worden deze in een container geplaatst om te worden uitgevoerd op Azure Kubernetes Service (AKS). Met virtuele-machineschaalsets, App Service of AKS als onderliggende infrastructuur wordt het schalen van toepassingen vereenvoudigd door onmiddellijk nieuwe VM's in te richten en de stateless onderdelen van toepassingen te repliceren om tegemoet te komen aan de aanvragen, maar vaak is de database een knelpunt als gecentraliseerd stateful onderdeel.

Met de functie leesreplica kunt u gegevens repliceren van een exemplaar van een flexibele Azure Database for MySQL-server naar een alleen-lezenserver. U kunt maximaal 10 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 op dezelfde manier beheert als uw bronexemplaren van Azure Database for MySQL flexibele server. Er worden factureringskosten in rekening gebracht voor elke leesreplica op basis van de ingerichte rekenkracht in vCores en opslag in GB/maand. Ga voor meer informatie naar het overzicht van prijzen.

Notitie

De functie leesreplica is alleen beschikbaar voor exemplaren van flexibele Azure Database for MySQL-servers in de prijscategorieën Algemeen gebruik of Bedrijfskritiek. Zorg ervoor dat de bronserver zich in een van deze prijscategorieën bevindt.

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.

Veelvoorkomende gebruiksvoorbeelden voor leesreplica

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.

Veelvoorkomende scenario's zijn:

  • Leesworkloads schalen die afkomstig zijn van de toepassing met behulp van een lichtgewicht verbindingsproxy zoals ProxySQL of een patroon op basis van microservices om uw leesquery's uit te schalen die afkomstig zijn van de toepassing om replica's te lezen
  • BI- of analytische rapportageworkloads kunnen leesreplica's gebruiken als gegevensbron voor rapportage
  • Voor IoT- of Productiescenario waarbij telemetriegegevens worden opgenomen in de MySQL-database-engine terwijl meerdere leesreplica's worden gebruikt voor het rapporteren van gegevens

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. Met Azure Database for MySQL Flexibele server kunt u leesreplica inrichten in alle ondersteuning voor Azure regio's waar azure Database for MySQL flexibele server beschikbaar is. Met deze functie kan een bronserver een replica in de gekoppelde regio of de universele replicaregio's hebben. Raadpleeg hier de lijst met Azure-regio's waar azure Database for MySQL flexibele server momenteel beschikbaar is.

Replica's maken

Als een bronserver geen bestaande replicaservers heeft, wordt de bron eerst opnieuw opgestart om zich voor te bereiden op replicatie.

Wanneer u de werkstroom voor het maken van replica's start, wordt er een leeg exemplaar van de flexibele 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.

Notitie

Leesreplica's worden gemaakt met dezelfde serverconfiguratie als de bron. De configuratie van de replicaserver kan worden gewijzigd nadat deze is gemaakt. 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. Het wordt aanbevolen om de configuratie van de replicaserver op gelijke of hogere waarden te houden dan de bron om ervoor te zorgen dat de replica de bron kan bijhouden.

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

Verbinding maken met een replica

Bij het maken neemt een replica de connectiviteitsmethode van de bronserver over. U kunt de connectiviteitsmethode van de replica niet wijzigen. Als de bronserver bijvoorbeeld privétoegang (VNet-integratie) heeft, kan de replica zich niet in openbare toegang (toegestane IP-adressen) bevinden.

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, zoals u dat zou doen op een normaal exemplaar van azure Database for MySQL flexibele 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 -p

Voer bij de prompt het wachtwoord voor het gebruikersaccount in.

Replicatie bewaken

Azure Database for MySQL flexibele server 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.

Belangrijk

Read Replica maakt gebruik van replicatietechnologie op basis van opslag, die niet langer de metrische gegevens 'SLAVE_IO_RUNNING'/'REPLICA_IO_RUNNING' gebruikt die beschikbaar is in de opdracht SHOW SLAVE STATUS/SHOW REPLICA STATUS van MySQL. Deze waarde wordt altijd weergegeven als Nee en wijst niet op de replicatiestatus. Als u de juiste status van replicatie wilt weten, raadpleegt u de metrische replicatiegegevens : Replica-IO-status en SQL-status van replica onder de blade Bewaking.

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.

Leesreplica's zijn bedoeld voor het schalen van leesintensieve werkbelastingen en zijn niet ontworpen om te voldoen aan hoge beschikbaarheidsbehoeften van een server. Het stoppen van de replicatie op leesreplica om deze online te brengen in de leesschrijfmodus is de manier waarop deze handmatige failover wordt uitgevoerd.

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 wilt uitvoeren naar een replica:

  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 toepassing ondervindt, is afhankelijk van wanneer u een probleem detecteert en stap 1 en 2 hierboven uitvoert.

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 flexibele server. GTID wordt ondersteund op versie 5.7 en 8.0. Raadpleeg de replicatie van MySQL met GTID-documentatie voor meer informatie over GTID en hoe deze wordt gebruikt in replicatie.

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.

Voor flexibele Azure Database for MySQL-serverexemplaren waarvoor de functie Hoge beschikbaarheid is ingeschakeld, is de standaardwaarde ingesteld op ON.

Notitie

  • Nadat GTID is ingeschakeld, kunt u dit niet meer uitschakelen. Als u GTID wilt uitschakelen, neemt u contact op met de ondersteuning.
  • U kunt GTID's wijzigen van de ene waarde in een andere stap per keer in oplopende volgorde van modi. 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.
  • Het is raadzaam enforce_gtid_consistency in te stellen op AAN voordat u gtid_mode=AAN kunt instellen.

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

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

Overwegingen en beperkingen

Scenario Beperking/overweging
Replica op server in Burstable-prijscategorie Niet ondersteund
Prijzen De kosten voor het uitvoeren van de replicaserver zijn gebaseerd op de regio waar de replicaserver wordt uitgevoerd
Bronserver opnieuw opstarten Wanneer u een replica maakt voor een bron die geen bestaande replica's heeft, wordt de bron eerst opnieuw opgestart om zich voor te bereiden op replicatie. Neem hier rekening mee en voer deze bewerkingen uit tijdens een dalperiode
Nieuwe replica's Er wordt een leesreplica gemaakt als een nieuw exemplaar van een flexibele 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 rekenlaag kan ook onafhankelijk worden gewijzigd.

BELANGRIJK : voordat een configuratie van een bronserver wordt bijgewerkt naar nieuwe waarden, werkt u de replicaconfiguratie bij 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.
Verbinding maken iviteitsmethode 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:
- innodb_file_per_table
- log_bin_trust_function_creators
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.
Parameters op sessieniveau Bij het configureren van parameters op sessieniveau, zoals 'foreign_keys_checks' op de leesreplica, moet u ervoor zorgen dat de parameterwaarden die op de leesreplica worden ingesteld, consistent zijn met die van de bronserver.
Voeg AUTO_INCREMENT kolom Primaire sleutel toe aan de bestaande tabel op de bronserver. Het is niet raadzaam om de tabel te wijzigen met AUTO_INCREMENT na het maken van een leesreplica, omdat deze de replicatie onderbreekt. Maar als u het kolombericht voor automatische verhoging wilt toevoegen aan het maken van een replicaserver, raden we deze twee benaderingen aan:
- Maak een nieuwe tabel met hetzelfde schema van de tabel die u wilt wijzigen. Wijzig in de nieuwe tabel de kolom met AUTO_INCREMENT en herstel vervolgens de gegevens uit de oorspronkelijke tabel. Verwijder de oude tabel en wijzig de naam ervan in de bron. Hiervoor hoeven we de replicaserver niet te verwijderen, maar er zijn mogelijk grote kosten nodig voor het maken van een back-uptabel.
- De andere snellere methode is het opnieuw maken van de replica nadat alle kolommen voor automatisch verhogen zijn toegevoegd.
Overige - Het maken van een replica van een replica wordt niet ondersteund.
- In-memory tabellen kunnen ertoe leiden 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