Dela via

Läsa repliker i Azure Database for MySQL

MySQL är en av de populära databasmotorerna för att köra webb- och mobilprogram i internetskala. Många kunder använder Azure Database for MySQL för en mängd olika program, inklusive onlineutbildning, videoströmning, digitala betalningar, e-handel, spel, nyhetsportaler, myndigheter och sjukvårdswebbplatser. Dessa tjänster måste kunna fungera och skalas när trafiken på webben eller mobilprogrammet ökar.

På programsidan använder utvecklare vanligtvis Java eller PHP. De migrerar programmet för att köras på Azure Virtual Machine Scale Sets, Azure App Services eller containerisera det 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 tillgodose begäranden. Databasen blir dock ofta en flaskhals som en 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. Repliker uppdateras asynkront med hjälp av MySQL-motorns inbyggda binärloggfil (binlog)-baserad replikeringsteknik. Mer information om binlogreplikering finns i översikten över Replikering av MySQL-binlog.

Du hanterar repliker som nya servrar, precis 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 per månad. Mer information finns i prissättning.

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 vi tar bort termen från programvaran tar vi bort den från den här artikeln.

Vanliga användningsfall för läsreplik

Funktionen läsreplik hjälper dig att förbättra prestanda och skala för läsintensiva arbetsbelastningar. Du kan isolera läsarbetsbelastningar till replikerna samtidigt som du dirigerar skrivarbetsbelastningar till källan.

Vanliga scenarier är:

  • Skala läsarbetsbelastningar som kommer från programmet med hjälp av en enkel anslutningsproxy som ProxySQL eller använda ett mikrotjänstbaserat mönster för att skala ut läsfrågor som kommer från programmet för att läsa repliker
  • Använda läsrepliker som datakälla för BI- eller analysrapporteringsarbetsbelastningar
  • Mata in telemetriinformation i MySQL-databasmotorn när du använder flera läsrepliker för rapportering av data i IoT- eller tillverkningsscenarier

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 en skrivskyddad replik i alla Azure-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. Se här för att hitta listan över Azure-regioner där Azure Database for MySQL – flexibel server är tillgänglig idag.

Skapa en replik

När du startar arbetsflödet för att skapa repliker skapar du en tom Azure Database for MySQL – flexibel serverinstans. Den nya servern innehåller de 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

Du skapar skrivskyddade repliker med samma serverkonfiguration som källan. Du kan ändra konfigurationen av replikservern när du har skapat den. Du skapar alltid replikservern i samma resursgrupp och prenumeration som källservern. Om du vill skapa en replikserver i en annan resursgrupp eller en annan prenumeration kan du flytta replikservern när den har skapats. Behåll replikserverns konfiguration 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 du skapar en replik ärver den källserverns anslutningsmetod. Du kan inte ändra replikens anslutningsmetod. Om källservern till exempel använder privat åtkomst (VNet-integrering) kan repliken inte använda 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. Azure Monitor beräknar det här måttet med hjälp av måttet seconds_behind_master i MySQL-kommandot SHOW SLAVE STATUS . Ange en avisering för att meddela dig när replikeringsfördröjningen överskrider ett oacceptabelt tröskelvärde 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-kommandot.SHOW SLAVESTATUS'/'SHOWREPLICA 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 – Replikstatus IO och SQL-replikstatus under sidan Övervakning.

Stoppa replikering

Du kan stoppa replikeringen mellan en källserver och en replikserver. När du stoppar replikeringen mellan en källserver och en läsreplik blir replikservern en fristående server. Den fristående servern innehåller de data som var tillgängliga på replikservern när du startade kommandot stop replication. Den fristående servern synkroniserar inte data som saknas från källservern.

När du stoppar replikeringen till en replikserver förlorar replikservern alla länkar till den tidigare källservern och till andra replikservrar. Det finns ingen automatiserad redundans mellan en källserver och dess replikservrar.

Viktigt!

Du kan inte konvertera tillbaka den fristående servern till en replikserver. Innan du stoppar replikeringen på en läsreplik kontrollerar du att replikservern har alla data du behöver.

Mer information finns i stoppa replikeringen till en replik.

Redundans

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

Läsrepliker skalar läsintensiva arbetsbelastningar och ger inte hög tillgänglighet för en server. Du utför manuell redundans genom att stoppa replikeringen på en läsreplik genom att aktivera den i läs- och skrivläge.

Eftersom replikeringen är asynkron finns det en fördröjning mellan källan och repliken. Många faktorer påverkar mängden fördröjning, till exempel arbetsbelastningen på källservern och svarstiden mellan datacenter. I de flesta fall varierar replikfördröjningen mellan några sekunder och ett par minuter. Du kan spåra den faktiska replikeringsfördröjningen med hjälp av måttet Replikfördröjning , som är tillgängligt för varje replik. Det här måttet visar tiden sedan den senaste omspelade transaktionen. Vi rekommenderar att du identifierar din genomsnittliga fördröjning genom att observera replikfördröjningen över tid. 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

    Du måste stoppa replikeringen för att replikservern ska kunna acceptera skrivningar. Den här processen delänkar replikservern från källan. När du har initierat stoppreplikeringen tar det vanligtvis cirka två 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 bearbetar läsningar och skrivningar slutför du redundansväxlingen. Hur lång stilleståndstid programmet har beror på när du identifierar ett problem och slutför steg 1 och 2.

Global transaktionsidentifierare (GTID)

En global transaktionsidentifierare (GTID) är en unik identifierare som källservern skapar med varje bekräftad transaktion. Azure Database for MySQL – flexibel server inaktiverar GTID som standard. Version 5.7 och 8.0 stöder GTID. Mer information om GTID och hur replikering använder det finns i MySQL:s replikering med GTID-dokumentation .

Använd följande serverparametrar 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. Ange värdet 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.

Kommentar

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

När du har aktiverat GTID kan du inte inaktivera det. 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 du till exempel gtid_mode för närvarande är inställd på OFF_PERMISSIVEkan du ändra den till ON_PERMISSIVE men inte till ON.

För att hålla replikeringen konsekvent kan du inte uppdatera den för en primär server eller replikserver.

Ange enforce_gtid_consistency till ON före inställning gtid_mode till ON.

Om du vill aktivera GTID och konfigurera konsekvensbeteendet uppdaterar du gtid_mode serverparametrarna och enforce_gtid_consistency . Använd Konfigurera serverparametrar i Azure Database for MySQL – flexibel server med hjälp av Azure-portalen eller Konfigurera serverparametrar i Azure Database for MySQL – flexibel server med hjälp av Azure CLI.

Om en källserver aktiverar GTID (gtid_mode = ON), aktiverar nyligen skapade repliker även GTID och använder GTID-replikering. För att säkerställa replikeringskonsekvens kan du inte ändra gtid_mode när du har skapat primära servrar eller replikservrar med GTID aktiverat.

Beaktanden och begränsningar

Scenarium Begränsning/överväganden
Replik på servern på burstbar prisnivå Stöds inte
Prissättning Kostnaden för att köra replikservern beror på den region där replikservern körs.
Källserveravbrott/omstart Ingen omstart eller stilleståndstid krävs när du skapar en läsreplik. Den här åtgärden är en onlineåtgärd.
Nya repliker Du skapar en läsreplik som en ny Azure Database for MySQL – flexibel serverinstans. Du kan inte göra en befintlig server till en replik. Du kan inte skapa en replik av en annan läsreplik.
Replikkonfiguration Du skapar en replik med samma serverkonfiguration som källan. När du har skapat en replik kan du ändra flera inställningar oberoende av källservern: beräkningsgenerering, virtuella kärnor, lagring och kvarhållningsperiod för säkerhetskopior. Du kan också ändra beräkningsnivån oberoende av varandra.

VIKTIGT – Innan du uppdaterar en källserverkonfiguration till nya värden uppdaterar du replikkonfigurationen till lika med eller större 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 du skapar repliken. 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. Du kan inte göra den fristående servern till en replik igen.
Borttagna källservrar När du tar bort en källserver stoppas replikeringen till alla lästa repliker. 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 de föregående parametrarna 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 du ställer in på läsrepliken är konsekventa med källserverns värden.
Lägga till en AUTO_INCREMENT primärnyckelkolumn i den befintliga tabellen på källservern Vi rekommenderar inte att du ändrar tabellen med AUTO_INCREMENT när du har skapat en läsreplik, eftersom den här åtgärden bryter replikeringen. Om du vill lägga till en automatisk inkrementskolumn när du har skapat en replikserver bör du överväga följande metoder:
– Skapa en ny tabell med samma schema som den tabell som du vill ändra. I den nya tabellen ändrar du kolumnen med AUTO_INCREMENToch återställer sedan data från den ursprungliga tabellen. Släpp den gamla tabellen och byt namn på den i källan. Den här metoden kräver inte att replikservern tas bort, men det kan medföra en stor infogningskostnad för att skapa en säkerhetskopieringstabell.
– Å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. Den här begränsningen beror på MySQL-replikeringstekniken. Mer information finns i referensdokumentationen för MySQL.
– 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 mySQL-replikeringsbegränsningar i MySQL-dokumentationen.

Relaterat innehåll