Dela via

Läs repliker i Azure Database for MySQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for MySQL – flexibel server

MySQL är en av de populära databasmotorerna för att köra webb- och mobilprogram i internetskala. Många av våra kunder använder den för sina onlineutbildningstjänster, videoströmningstjänster, digitala betalningslösningar, e-handelsplattformar, speltjänster, nyhetsportaler, myndigheter och sjukvårdswebbplatser. Dessa tjänster krävs för att fungera och skala när trafiken på webben eller mobilprogrammet ökar.

På programsidan utvecklas programmet vanligtvis i Java eller PHP och migreras för att köras på Azure Virtual Machine Scale Sets eller Azure App Services eller är containerbaserade för att köras på Azure Kubernetes Service (AKS). Med Vm-skalningsuppsättning, App Service eller AKS som underliggande infrastruktur förenklas programskalning genom att omedelbart etablera nya virtuella datorer och replikera tillståndslösa komponenter i program för att hantera begäranden, men ofta blir databasen en flaskhals som centraliserad tillståndskänslig komponent.

Med funktionen skrivskyddad replik kan du replikera data från en Azure Database for MySQL – flexibel serverinstans till en skrivskyddad server. Du kan replikera från källservern till upp till 10 repliker. Replikerna uppdateras asynkront med MySQL-motorns interna replikeringsteknik som utgår från replikernas position i en binär loggfil (binlog). Mer information om binlogreplikering finns i översikten över Replikering av MySQL-binlog.

Repliker är nya servrar som du hanterar på samma sätt som dina Azure Database for MySQL-instanser för flexibel server. Du debiteras faktureringsavgifter för varje läsreplik baserat på den etablerade beräkningen i virtuella kärnor och lagring i GB/månad. Mer information finns i prissättning.

Kommentar

Funktionen för skrivskyddad replik är endast tillgänglig för Azure Database for MySQL– flexibla serverinstanser på prisnivåerna Generell användning eller Affärskritisk. Kontrollera att källservern finns på någon av dessa prisnivåer.

Mer information om funktioner och problem med MySQL-replikering finns i dokumentationen om MySQL-replikering.

Kommentar

Den här artikeln innehåller referenser till termen slav, en term som Microsoft inte längre använder. När termen tas bort från programvaran tar vi bort den från den här artikeln.

Vanliga användningsfall för läsreplik

Funktionen med skrivskyddade repliker bidrar till att förbättra prestanda och skalning för läsintensiva arbetsbelastningar. Läsarbetsbelastningar kan isoleras till replikerna, medan skrivarbetsbelastningar kan dirigeras till källan.

Vanliga scenarier är:

  • Skala läsarbetsbelastningar som kommer från programmet med hjälp av enkel anslutningsproxy som ProxySQL eller använda mikrotjänstbaserat mönster för att skala ut läsfrågor som kommer från programmet för att läsa repliker
  • BI- eller analysrapporteringsarbetsbelastningar kan använda läsrepliker som datakälla för rapportering
  • För IoT- eller tillverkningsscenario där telemetriinformation matas in i MySQL-databasmotorn medan flera läsrepliker används för rapportering av data

Eftersom repliker är skrivskyddade minskar de inte skrivkapacitetsbelastningen direkt på källan. Den här funktionen är inte riktad mot skrivintensiva arbetsbelastningar.

Funktionen för läsreplik använder asynkron Replikering av MySQL. Funktionen är inte avsedd för synkrona replikeringsscenarier. Det finns en mätbar fördröjning mellan källan och repliken. Data på repliken blir så småningom konsekventa med data på källan. Använd den här funktionen för arbetsbelastningar som kan hantera den här fördröjningen.

Replikering mellan regioner

Du kan skapa en läsreplik i en annan region än källservern. Replikering mellan regioner kan vara användbart för scenarier som haveriberedskapsplanering eller om du vill att data ska vara närmare användarna. Med Azure Database for MySQL – flexibel server kan du etablera skrivskyddad replik i alla Azure Support regioner där Azure Database for MySQL – flexibel server är tillgänglig. Med den här funktionen kan en källserver ha en replik i sin kopplade region eller de universella replikregionerna. Här hittar du listan över Azure-regioner där Azure Database for MySQL – flexibel server är tillgänglig idag.

Skapa en replik

Om en källserver inte har några befintliga replikservrar startar källan först om för att förbereda sig för replikering.

När du startar arbetsflödet för att skapa replik skapas en tom Azure Database for MySQL – flexibel serverinstans. Den nya servern är fylld med data som fanns på källservern. Skapandetiden beror på mängden data på källan och tiden sedan den senaste veckovisa fullständiga säkerhetskopieringen. Tiden kan variera från några minuter till flera timmar.

Kommentar

Läsrepliker skapas med samma serverkonfiguration som källan. Konfigurationen av replikservern kan ändras när den har skapats. Replikservern skapas alltid i samma resursgrupp och samma prenumeration som källservern. Om du vill skapa en replikserver till en annan resursgrupp eller en annan prenumeration kan du flytta replikservern när den har skapats. Vi rekommenderar att replikserverns konfiguration hålls på samma eller högre värden än källan för att säkerställa att repliken kan hålla jämna tid med källan.

Lär dig hur du skapar en skrivskyddad replik i Azure-portalen.

Ansluta till en replik

När en replik skapas ärver den anslutningsmetoden för källservern. Du kan inte ändra replikens anslutningsmetod. Om källservern till exempel har privat åtkomst (VNet-integrering) kan repliken inte finnas i offentlig åtkomst (tillåtna IP-adresser).

Repliken ärver administratörskontot från källservern. Alla användarkonton på källservern replikeras till läsreplikerna. Du kan bara ansluta till en skrivskyddad replik med hjälp av de användarkonton som är tillgängliga på källservern.

Du kan ansluta till repliken med hjälp av dess värdnamn och ett giltigt användarkonto, precis som på en vanlig Azure Database for MySQL – flexibel serverinstans. För en server med namnet myreplica med administratörsanvändarnamnet myadmin kan du ansluta till repliken med hjälp av mysql CLI:

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

Ange lösenordet för användarkontot när du uppmanas att göra det.

Övervaka replikering

Azure Database for MySQL – flexibel server tillhandahåller måttet Replikeringsfördröjning i sekunder i Azure Monitor. Det här måttet är endast tillgängligt för repliker. Det här måttet beräknas med hjälp av det mått som seconds_behind_master är tillgängligt i MySQL:s SHOW SLAVE STATUS kommando. Ange en avisering som informerar dig när replikeringsfördröjningen når ett värde som inte är acceptabelt för din arbetsbelastning.

Om du ser ökad replikeringsfördröjning kan du felsöka replikeringsfördröjning för att felsöka och förstå möjliga orsaker.

Viktigt!

Read Replica använder lagringsbaserad replikeringsteknik, som inte längre använder måttet "SLAVE_IO_RUNNING"/"REPLICA_IO_RUNNING" som är tillgängligt i MySQL:s kommandot "SHOW SLAVE STATUS"/"SHOW REPLICA STATUS". Det här värdet visas alltid som "Nej" och är inte ett tecken på replikeringsstatus. Information om rätt status för replikering finns i replikeringsmått – Replik-I/O-status och SQL-replikstatus under bladet Övervakning.

Stoppa replikering

Du kan stoppa replikeringen mellan en källa och en replik. När replikeringen har stoppats mellan en källserver och en läsreplik blir repliken en fristående server. Data på den fristående servern är de data som var tillgängliga på repliken när kommandot stop replication startades. Den fristående servern kommer inte ikapp källservern.

När du väljer att stoppa replikeringen till en replik förlorar den alla länkar till dess tidigare källa och andra repliker. Det finns ingen automatiserad redundansväxling mellan en källa och dess replik.

Viktigt!

Den fristående servern kan inte göras till en replik igen. Innan du stoppar replikeringen på en läsreplik kontrollerar du att repliken har alla data som du behöver.

Lär dig hur du stoppar replikeringen till en replik.

Redundans

Det finns ingen automatiserad redundans mellan käll- och replikservrar.

Läsrepliker är avsedda för skalning av läsintensiva arbetsbelastningar och är inte utformade för att uppfylla serverns behov av hög tillgänglighet. Att stoppa replikeringen på läsrepliken för att få den online i lässkrivningsläge är det sätt på vilket den här manuella redundansväxlingen utförs.

Eftersom replikeringen är asynkron finns det en fördröjning mellan källan och repliken. Mängden fördröjning kan påverkas av många faktorer som hur tung arbetsbelastningen som körs på källservern är och svarstiden mellan datacenter. I de flesta fall varierar replikfördröjning mellan några sekunder och några minuter. Du kan spåra den faktiska replikeringsfördröjningen med måttet Replikfördröjning, som är tillgänglig för varje replik. Det här måttet visar tiden sedan den senaste omspelade transaktionen. Vi rekommenderar att du identifierar den genomsnittliga fördröjningen genom att observera replikfördröjningen under en viss tidsperiod. Du kan ange en avisering om replikfördröjning, så att du kan vidta åtgärder om den hamnar utanför det förväntade intervallet.

Dricks

Om du redundansväxlar till repliken anger fördröjningen vid den tidpunkt då du avlänkar repliken från källan hur mycket data som går förlorade.

När du har bestämt dig för att redundansväxla till en replik:

  1. Stoppa replikeringen till repliken
    Det här steget är nödvändigt för att replikservern ska kunna acceptera skrivningar. Som en del av den här processen kopplas replikservern bort från källan. När du har initierat stoppa replikeringen tar det vanligtvis cirka 2 minuter att slutföra serverdelsprocessen. Se avsnittet stoppa replikering i den här artikeln för att förstå konsekvenserna av den här åtgärden.

  2. Peka ditt program till (tidigare) repliken
    Varje server har en unik anslutningssträng. Uppdatera programmet så att det pekar på (tidigare) repliken i stället för källan.

När programmet har bearbetat läsningar och skrivningar har du slutfört redundansväxlingen. Hur lång stilleståndstid programmet har beror på när du upptäcker ett problem och slutför steg 1 och 2 ovan.

Global transaktionsidentifierare (GTID)

Global transaktionsidentifierare (GTID) är en unik identifierare som skapats med varje bekräftad transaktion på en källserver och är AV som standard i Azure Database for MySQL – flexibel server. GTID stöds i versionerna 5.7 och 8.0. Mer information om GTID och hur det används i replikering finns i MySQL:s replikering med GTID-dokumentationen .

Följande serverparametrar är tillgängliga för att konfigurera GTID:

Serverparameter Beskrivning Standardvärde Värden
gtid_mode Anger om GTID används för att identifiera transaktioner. Ändringar mellan lägen kan bara göras ett steg i taget i stigande ordning (till exempel OFF -OFF_PERMISSIVE> ->ON_PERMISSIVE ->ON) OFF* OFF: Både nya transaktioner och replikeringstransaktioner måste vara anonyma
OFF_PERMISSIVE: Nya transaktioner är anonyma. Replikerade transaktioner kan antingen vara anonyma eller GTID-transaktioner.
ON_PERMISSIVE: Nya transaktioner är GTID-transaktioner. Replikerade transaktioner kan antingen vara anonyma eller GTID-transaktioner.
ON: Både nya och replikerade transaktioner måste vara GTID-transaktioner.
enforce_gtid_consistency Framtvingar GTID-konsekvens genom att endast tillåta körning av de instruktioner som kan loggas på ett transaktionssäkert sätt. Det här värdet måste anges till ON innan du aktiverar GTID-replikering. OFF* OFF: Alla transaktioner tillåts bryta mot GTID-konsekvens.
ON: Ingen transaktion tillåts bryta mot GTID-konsekvensen.
WARN: Alla transaktioner tillåts bryta mot GTID-konsekvens, men en varning genereras.

För Azure Database for MySQL – flexibel server-instanser som har funktionen Hög tillgänglighet aktiverad är standardvärdet inställt på ON.

Kommentar

  • När GTID är aktivt kan du inte avaktivera det igen. Kontakta supporten om du behöver inaktivera GTID.
  • Du kan ändra GTID:er från ett värde till ett annat endast ett steg i taget i stigande ordning med lägen. Om gtid_mode för närvarande är inställt på OFF_PERMISSIVE kan du till exempel ändra till ON_PERMISSIVE men inte till PÅ.
  • Om du vill hålla replikeringen konsekvent kan du inte uppdatera den för en huvud-/replikserver.
  • Vi rekommenderar att du ställer in enforce_gtid_consistency på PÅ innan du kan ange gtid_mode=ON.

Om du vill aktivera GTID och konfigurera konsekvensbeteendet uppdaterar gtid_mode du serverparametrarna och enforce_gtid_consistency med hjälp av Azure Portal eller Azure CLI.

Om GTID är aktiverat på en källserver (gtid_mode = ON), har nyligen skapade repliker också GTID aktiverat och använder GTID-replikering. För att säkerställa att replikeringen är konsekvent gtid_mode kan den inte ändras när huvudservern eller replikservern har skapats med GTID aktiverat.

Beaktanden och begränsningar

Scenario Begränsning/överväganden
Replik på servern på burstbar prisnivå Stöds inte
Prissättning Kostnaden för att köra replikservern baseras på den region där replikservern körs
Omstart av källserver När du skapar en replik för en källa som inte har några befintliga repliker startar källan först om för att förbereda sig för replikering. Ta hänsyn till detta och utför dessa åtgärder under en låg belastningsperiod
Nya repliker En läsreplik skapas som en ny Azure Database for MySQL – flexibel serverinstans. Det går inte att göra en befintlig server till en replik. Du kan inte skapa en replik av en annan läsreplik.
Replikkonfiguration En replik skapas med samma serverkonfiguration som källan. När en replik har skapats kan flera inställningar ändras oberoende av källservern: beräkningsgenerering, virtuella kärnor, lagring och kvarhållningsperiod för säkerhetskopior. Beräkningsnivån kan också ändras oberoende av varandra.

VIKTIGT – Innan en källserverkonfiguration uppdateras till nya värden uppdaterar du replikkonfigurationen till lika med eller högre värden. På så sätt säkerställer du att repliken klarar alla ändringar som görs av källan.
Anslutningsmetoden och parameterinställningarna ärvs från källservern till repliken när repliken skapas. Därefter är replikens regler oberoende.
Stoppade repliker Om du stoppar replikeringen mellan en källserver och en läsreplik blir den stoppade repliken en fristående server som accepterar både läsningar och skrivningar. Den fristående servern kan inte göras till en replik igen.
Borttagna källservrar och fristående servrar När en källserver tas bort stoppas replikeringen till alla läsrepliker. Dessa repliker blir automatiskt fristående servrar och kan acceptera både läsningar och skrivningar. Själva källservern tas bort.
Användarkonton Användare på källservern replikeras till läsreplikerna. Du kan bara ansluta till en skrivskyddad replik med hjälp av de användarkonton som är tillgängliga på källservern.
Serverparametrar I syfte att förhindra att data blir osynkroniserade samt att undvika potentiell dataförlust eller skadade data är vissa serverparametrar låsta från att uppdateras vid användning av skrivskyddade repliker.
Följande serverparametrar är låsta på både käll- och replikservrarna:
- innodb_file_per_table
- log_bin_trust_function_creators
Parametern event_scheduler är låst på replikservrarna.
Om du vill uppdatera någon av ovanstående parametrar på källservern tar du bort replikservrar, uppdaterar parametervärdet på källan och återskapar repliker.
Parametrar på sessionsnivå När du konfigurerar parametrar på sessionsnivå, till exempel "foreign_keys_checks" på läsrepliken, kontrollerar du att parametervärdena som anges på läsrepliken är konsekventa med källserverns.
Lägga till AUTO_INCREMENT primärnyckelkolumn i den befintliga tabellen på källservern. Vi rekommenderar inte att du ändrar tabellen med AUTO_INCREMENT efter skapandet av skrivskyddade repliker, eftersom replikeringen bryts. Men om du vill lägga till kolumnen för automatisk ökning efter att ha skapat en replikserver rekommenderar vi följande två metoder:
– Skapa en ny tabell med samma tabellschema som du vill ändra. I den nya tabellen ändrar du kolumnen med AUTO_INCREMENT och återställer sedan data från den ursprungliga tabellen. Släpp den gamla tabellen och byt namn på den i källan. Det här behöver inte vi ta bort replikservern, men kan behöva stora infogningskostnader för att skapa en säkerhetskopieringstabell.
– Den andra snabbare metoden är att återskapa repliken när du har lagt till alla automatiska inkrementskolumner.
Övrigt – Det går inte att skapa en replik av en replik.
– Minnesinterna tabeller kan leda till att repliker blir osynkroniserade. Detta är en begränsning av MySQL-replikeringstekniken. Mer information finns i MySQL-referensdokumentationen .
– Kontrollera att källservertabellerna har primära nycklar. Brist på primära nycklar kan leda till replikeringsfördröjning mellan källan och replikerna.
– Granska den fullständiga listan över begränsningar för MySQL-replikering i MySQL-dokumentationen

Nästa steg