Skrivskyddad replik i Azure Database for MySQL

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

Med funktionen för skrivskyddade repliker kan du replikera data från en Azure Database for MySQL-server till en skrivskyddad server. Du kan replikera från källservern till upp till fem 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å liknande sätt som vanliga Azure Database for MySQL-servrar. För varje läsreplik debiteras du för den etablerade beräkningen i virtuella kärnor och lagring i GB/månad.

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

När du ska använda en skrivskyddad replik

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.

Ett vanligt scenario är att låta BI och analytiska arbetsbelastningar använda de skrivskyddade replikerna som datakälla vid rapportering.

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 blir 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.

Du kan ha en källserver i valfri Azure Database for MySQL-region. En källserver kan ha en replik i sin kopplade region eller de universella replikregionerna. Följande bild visar vilka replikregioner som är tillgängliga beroende på källregionen.

Universella replikeringsregioner

Du kan skapa en läsreplik i någon av följande regioner, oavsett var källservern finns. De universella replikregioner som stöds är:

Länkade regioner

Förutom de universella replikregionerna kan du skapa en skrivskyddad replik i den Azure-kopplade regionen på källservern. Om du inte känner till regionens par kan du lära dig mer i artikeln Azure Paired Regions (Länkade regioner i Azure).

Om du använder repliker mellan regioner för planering av haveriberedskap rekommenderar vi att du skapar repliken i den kopplade regionen i stället för någon av de andra regionerna. Parkopplade regioner undviker samtidiga uppdateringar och prioriterar fysisk isolering och datahemvist.

Det finns dock begränsningar att tänka på:

• Regional tillgänglighet: Azure Database for MySQL är tillgängligt i Frankrike, centrala, Förenade Arabemiraten, norra och Tyskland, centrala. Deras kopplade regioner är dock inte tillgängliga.

• Enkelriktade par: Vissa Azure-regioner är endast kopplade i en riktning. Dessa regioner inkluderar Västra Indien, Brasilien, södra och US Gov Virginia. Det innebär att en källserver i Indien, västra, kan skapa en replik i södra Indien. En källserver i södra Indien kan dock inte skapa en replik i Indien, västra. Detta beror på att Västra Indiens sekundära region är Södra Indien, men Södra Indiens sekundära region är inte Västra Indien.

Skapa en replik

När du startar arbetsflödet för att skapa repliker skapas en tom Azure Database for MySQL-server. 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. 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.

Varje replik är aktiverad för automatisk ökning av lagring. Funktionen för automatisk utökning gör att repliken kan hålla jämna steg med de data som replikeras till den och förhindra ett avbrott i replikeringen som orsakas av fel som inte är lagringsbara.

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

Ansluta till en replik

När en replik skapas ärver den brandväggsreglerna för källservern. Därefter är dessa regler oberoende av källservern.

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 dess värdnamn och ett giltigt användarkonto, precis som på en vanlig Azure Database for MySQL-server. 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@myreplica -p

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

Övervaka replikering

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

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.

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

Redundans

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

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.

När du har bestämt dig för att redundansväxlar 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 delänkas replikservern 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 niska veze. 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 dina programupplevelser beror på när du identifierar ett problem och slutför steg 1 och 2 som anges tidigare.

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. GTID stöds på versionerna 5.7 och 8.0 och endast på servrar som stöder lagring upp till 16 TB (generell lagring v2). Mer information om GTID och hur det används i replikering finns i MySQL:s replikering med GTID-dokumentationen .

MySQL stöder två typer av transaktioner: GTID-transaktioner (identifieras med GTID) och anonyma transaktioner (har ingen allokerad GTID)

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

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

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 huvud- eller replikservern har skapats med GTID aktiverat.

Beaktanden och begränsningar

Prisnivåer

Läsrepliker är för närvarande endast tillgängliga på prisnivåerna Generell användning och Minnesoptimerad.

Omstart av källserver

Server som har generell lagring v1, parametern log_bin är AV som standard. Värdet aktiveras när du skapar den första skrivskyddade repliken. Om en källserver inte har några befintliga skrivskyddade repliker startar källservern först om för att förbereda sig för replikering. Överväg att starta om servern och utföra den här åtgärden under tider med låg belastning.

Källserver som har generell lagring v2, parametern log_bin är PÅ som standard och kräver ingen omstart när du lägger till en läsreplik.

Nya repliker

En läsreplik skapas som en ny Azure Database for MySQL-server. 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. Prisnivån kan också ändras oberoende av varandra, förutom till eller från Basic-nivån.

Brandväggsregler och parameterinställningar ä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.

GTID

GTID stöds på:

• MySQL-versionerna 5.7 och 8.0.
• Servrar som stöder lagring upp till 16 TB. I artikeln om priser finns en fullständig lista över vilka regioner som har stöd för lagring på 16 TB.

GTID är AV som standard. När GTID är aktivt kan du inte avaktivera det igen. Kontakta supporten om du behöver avaktivera GTID.

Om GTID är aktiverat på en källserver så får även nya replikservrar GTID och GTID-replikering aktiverat. Om du vill hålla replikeringen konsekvent kan du inte uppdatera gtid_mode på käll- eller replikservern eller replikservern.

Ö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 MySQL-replikeringsbegränsningar i MySQL-dokumentationen

Nästa steg

• Lär dig hur du skapar och hanterar läsrepliker med hjälp av Azure-portalen
• Lär dig hur du skapar och hanterar läsrepliker med hjälp av Azure CLI och REST API