Delen via

Replica's lezen in Azure Database for MySQL

MySQL is een van de populaire database-engines voor het uitvoeren van webtoepassingen en mobiele toepassingen op het internet. Veel klanten gebruiken Azure Database for MySQL voor een breed scala aan toepassingen, waaronder online onderwijs, videostreaming, digitale betalingen, e-commerce, gaming, nieuwsportals, overheids- en gezondheidszorgwebsites. Deze services moeten kunnen worden gebruikt en geschaald naarmate het verkeer op internet of mobiele toepassingen toeneemt.

Aan de kant van toepassingen gebruiken ontwikkelaars doorgaans Java of PHP. Ze migreren de toepassing die moet worden uitgevoerd op Azure Virtual Machine Scale Sets, Azure App Services of containeriseren deze om te worden uitgevoerd op Azure Kubernetes Service (AKS). Met Virtual Machine Scale Set, 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. De database wordt echter vaak een knelpunt als een gecentraliseerd stateful onderdeel.

Met de functie leesreplica kunt u gegevens van een Exemplaar van Azure Database for MySQL Flexible Server repliceren naar een alleen-lezenserver. U kunt maximaal 10 replica's van de bronserver repliceren. Replica's worden asynchroon bijgewerkt met behulp van de systeemeigen binaire logboekbestandstechnologie (binlog) van de MySQL-engine. Zie het overzicht van de replicatie van binlog-binlog in MySQL voor meer informatie over binlog-replicatie.

U beheert replica's als nieuwe servers, net zoals uw bronexemplaren van Azure Database for MySQL Flexible Server. Er worden kosten in rekening gebracht voor elke leesreplica op basis van de ingerichte rekenkracht in vCores en opslag in GB per maand. Ga voor meer informatie naar het overzicht van prijzen.

De functie leesreplica is alleen beschikbaar voor Azure Database for MySQL Flexible Server-exemplaren 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. Wanneer we de term uit de software verwijderen, verwijderen we deze uit dit artikel.

Veelvoorkomende gebruiksvoorbeelden voor leesreplica

Met de functie leesreplica kunt u de prestaties en schaal van leesintensieve workloads verbeteren. U kunt leesworkloads isoleren naar de replica's, terwijl u schrijfworkloads naar de bron stuurt.

Veelvoorkomende scenario's zijn:

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

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 Flexible Server kunt u een leesreplica inrichten in alle ondersteunde Azure-regio's waar Azure Database for MySQL Flexible Server beschikbaar is. Met deze functie kan een bronserver een replica in de gekoppelde regio of de universele replicaregio's hebben. Hier vindt u de lijst met Azure-regio's waar Azure Database for MySQL Flexible Server momenteel beschikbaar is.

Replica's maken

Wanneer u de werkstroom voor het maken van replica's start, maakt u een leeg Exemplaar van Azure Database for MySQL Flexible Server. De nieuwe server bevat 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

U maakt leesreplica's met dezelfde serverconfiguratie als de bron. U kunt de configuratie van de replicaserver wijzigen nadat deze is gemaakt. U maakt altijd de replicaserver in dezelfde resourcegroep en hetzelfde abonnement als de bronserver. Als u een replicaserver in een andere resourcegroep of een ander abonnement wilt maken, kunt u de replicaserver na het maken verplaatsen . Behoud de configuratie van de replicaserver op gelijke of hogere waarden 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

Wanneer u een replica maakt, neemt deze de connectiviteitsmethode van de bronserver over. U kunt de connectiviteitsmethode van de replica niet wijzigen. Als de bronserver bijvoorbeeld privétoegang (VNet-integratie) gebruikt, kan de replica geen openbare toegang (toegestane IP-adressen) gebruiken.

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 zoals u dat zou doen op een normaal Exemplaar van Azure Database for MySQL Flexible 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 Flexible Server biedt de replicatievertraging in seconden metrische gegevens in Azure Monitor. Deze metrische waarde is alleen beschikbaar voor replica's. Azure Monitor berekent deze metrische waarde met behulp van de metrische waarde in de seconds_behind_master opdracht van SHOW SLAVE STATUS MySQL. Stel een waarschuwing in om u te waarschuwen wanneer de replicatievertraging een onaanvaardbare drempelwaarde voor uw workload overschrijdt.

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 gebruikmaakt van de metrische gegevens die beschikbaar zijn in de SLAVE_IO_RUNNING/REPLICA_IO_RUNNING opdracht van SHOW SLAVESTATUS'/'SHOWREPLICA STATUS MySQL. Deze waarde wordt altijd weergegeven als Nee en wijst niet op de replicatiestatus. Als u de juiste replicatiestatus wilt weten, raadpleegt u de metrische replicatiegegevens : Replicastatus IO en SQL-status van replica onder de pagina Bewaking.

Replicatie stoppen

U kunt de replicatie tussen een bronserver en een replicaserver stoppen. Wanneer u de replicatie tussen een bronserver en een leesreplica stopt, wordt de replicaserver een zelfstandige server. De zelfstandige server bevat de gegevens die beschikbaar waren op de replicaserver toen u de opdracht replicatie stoppen startte. De zelfstandige server synchroniseert geen ontbrekende gegevens van de bronserver.

Wanneer u de replicatie naar een replicaserver stopt, verliest de replicaserver alle koppelingen naar de vorige bronserver en andere replicaservers. Er is geen automatische failover tussen een bronserver en de bijbehorende replicaservers.

Belangrijk

U kunt de zelfstandige server niet terug converteren naar een replicaserver. Voordat u de replicatie op een leesreplica stopt, moet u ervoor zorgen dat de replicaserver alle gegevens bevat die u nodig hebt.

Zie replicatie stoppen naar een replica voor meer informatie.

Overgang bij uitval

Er is geen automatische failover tussen bron- en replicaservers.

Leesreplica's schalen leesintensieve workloads en bieden geen hoge beschikbaarheid voor een server. U voert handmatige failover uit door replicatie op een leesreplica te stoppen door deze online te brengen in de lees-/schrijfmodus.

Omdat replicatie asynchroon is, is er een vertraging tussen de bron en de replica. Veel factoren beïnvloeden de hoeveelheid vertraging, zoals de workload op de bronserver en de latentie tussen datacenters. In de meeste gevallen varieert de replicavertraging tussen een paar 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 uw gemiddelde vertraging te identificeren door de replicavertraging in de loop van de tijd te observeren. U kunt een waarschuwing instellen voor replicavertraging, zodat u actie kunt ondernemen als deze buiten het verwachte bereik valt.

Aanbeveling

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 een failover naar een replica hebt uitgevoerd:

  1. Replicatie naar de replica stoppen

    U moet de replicatie stoppen om de replicaserver schrijfbewerkingen te laten accepteren. Met dit proces wordt de replicaserver losgekoppeld van de bron. Nadat u de replicatie hebt gestart, duurt het ongeveer twee 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.

Wanneer uw toepassing lees- en schrijfbewerkingen verwerkt, voltooit u de failover. De hoeveelheid downtime die uw toepassing ondervindt, is afhankelijk van wanneer u een probleem detecteert en stap 1 en 2 voltooit.

Globale transactie-id (GTID)

Een globale transactie-id (GTID) is een unieke id die door de bronserver wordt gemaakt bij elke doorgevoerde transactie. Azure Database for MySQL Flexible Server schakelt standaard GTID uit. Versies 5.7 en 8.0 ondersteunen GTID. Zie de replicatie van MySQL met GTID-documentatie voor meer informatie over GTID en hoe replicatie deze gebruikt.

Gebruik de volgende serverparameters om GTID te configureren:

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. Stel de waarde ON in voordat u GTID-replicatie inschakelt. 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

Voor Azure Database for MySQL Flexible Server-exemplaren waarvoor de functie Hoge beschikbaarheid is ingeschakeld, is de standaardwaarde ingesteld op ON.

Nadat u GTID hebt ingeschakeld, kunt u deze niet 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 dit bijvoorbeeld gtid_mode is ingesteld op OFF_PERMISSIVE, kunt u deze ON_PERMISSIVE wijzigen in maar niet in ON.

Als u de replicatie consistent wilt houden, kunt u deze niet bijwerken voor een primaire server of replicaserver.

Ingesteld enforce_gtid_consistency op ON voordat u instelt gtid_mode op ON.

Als u GTID wilt inschakelen en het consistentiegedrag wilt configureren, werkt u de gtid_mode parameters en enforce_gtid_consistency serverparameters bij. Gebruik Serverparameters configureren in Azure Database for MySQL - Flexible Server met behulp van Azure Portal of serverparameters configureren in Azure Database for MySQL - Flexible Server met behulp van de Azure CLI.

Als een bronserver GTID (gtid_mode = ON) inschakelt, schakelt u zojuist gemaakte replica's ook GTID in en gebruikt u GTID-replicatie. Om replicatieconsistentie te garanderen, kunt u niet wijzigen gtid_mode nadat primaire of replicaservers zijn gemaakt waarvoor GTID is ingeschakeld.

Overwegingen en beperkingen

Scenariobeschrijving Beperking/overweging
Replica op server in Burstable-prijscategorie Niet ondersteund
Prijzen De kosten voor het uitvoeren van de replicaserver zijn afhankelijk van de regio waar de replicaserver wordt uitgevoerd.
Downtime van bronserver/opnieuw opstarten Er is geen herstart of downtime nodig bij het maken van een leesreplica. Deze bewerking is een onlinebewerking.
Nieuwe replica's U maakt een leesreplica als een nieuw exemplaar van Azure Database for MySQL Flexible Server. U kunt geen bestaande server in een replica maken. U kunt geen replica van een andere leesreplica maken.
Replicaconfiguratie U maakt een replica met dezelfde serverconfiguratie als de bron. Nadat u een replica hebt gemaakt, kunt u verschillende instellingen onafhankelijk van de bronserver wijzigen: compute-generatie, vCores, opslag en bewaarperiode voor back-ups. U kunt ook de rekenlaag onafhankelijk wijzigen.

BELANGRIJK : voordat u een configuratie van een bronserver bijwerkt naar nieuwe waarden, moet u de replicaconfiguratie bijwerken op gelijke of hogere waarden. Met deze actie wordt ervoor gezorgd dat in de replica alle wijzigingen worden doorgevoerd die in de bronserver zijn aangebracht.
Connectiviteitsmethode en parameterinstellingen worden overgenomen van de bronserver naar de replica wanneer u de replica maakt. 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. U kunt de zelfstandige server niet opnieuw in een replica maken.
Verwijderde bronservers Wanneer u een bronserver verwijdert, stopt de replicatie 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 voorgaande 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 u op de leesreplica instelt, consistent zijn met die van de bronserver.
Een kolom AUTO_INCREMENT primaire sleutel toevoegen aan de bestaande tabel op de bronserver Het is niet raadzaam om de tabel AUTO_INCREMENT te wijzigen nadat u een leesreplica hebt gemaakt, omdat deze actie de replicatie onderbreekt. Als u een kolom voor automatische verhoging wilt toevoegen nadat u een replicaserver hebt gemaakt, kunt u de volgende methoden overwegen:
- Maak een nieuwe tabel met hetzelfde schema als de tabel die u wilt wijzigen. Wijzig in de nieuwe tabel de kolom met AUTO_INCREMENTen herstel vervolgens de gegevens uit de oorspronkelijke tabel. Verwijder de oude tabel en wijzig de naam ervan in de bron; Voor deze benadering is het verwijderen van de replicaserver niet vereist, maar er kunnen grote kosten in rekening worden gebracht voor het maken van een back-uptabel.
- Maak de replica opnieuw nadat u alle kolommen voor automatisch verhogen hebt 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. Deze beperking wordt veroorzaakt door de MySQL-replicatietechnologie. Zie 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.

Gerelateerde inhoud