Skrivskyddad replik i Azure Database for MariaDB
Viktigt!
Azure Database for MariaDB är på väg att dras tillbaka. Vi rekommenderar starkt att du migrerar till Azure Database for MySQL. Mer information om hur du migrerar till Azure Database for MySQL finns i Vad händer med Azure Database for MariaDB?.
Med funktionen för skrivskyddade repliker kan du replikera data från en Azure Database for MariaDB-server till en skrivskyddad server. Du kan replikera från källservern till upp till fem repliker. Repliker uppdateras asynkront med hjälp av MariaDB-motorns binärloggfil (binlog)-baserad replikeringsteknik med globalt transaktions-ID (GTID). Mer information om binlogreplikering finns i översikten över binlogreplikering.
Repliker är nya servrar som du hanterar på liknande sätt som vanliga Azure Database for MariaDB-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 GTID-replikering finns i dokumentationen om MariaDB-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.
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 den primära servern.
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 direkt skrivkapacitetsbelastningen på den primära servern. Den här funktionen är inte riktad mot skrivintensiva arbetsbelastningar.
Funktionen läsreplik använder asynkron replikering. 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å den primära. 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 MariaDB-region. En källserver kan ha en replik i sin kopplade region eller de universella replikregionerna. Bilden nedan 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:
Australien, östra, Australien, sydöstra, Brasilien, södra, Kanada, centrala, Kanada, östra, USA, centrala, Östra Asien, USA, östra, USA, östra 2, Japan, östra, Japan, västra, Korea, centrala, Sydkorea, södra, USA, norra centrala, Europa, norra centrala, USA, södra centrala, Sydostasien, Storbritannien, södra, Storbritannien, västra, Europa, västra, USA, västra, USA, västra 2, USA, västra centrala.
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 MariaDB är tillgängligt i Frankrike, centrala, Förenade Arabemiraten, norra och Tyskland, centrala. De parkopplade regionerna ä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
Viktigt!
Funktionen för skrivskyddad replik är endast tillgänglig för Azure Database for MariaDB-servrar på prisnivåerna Generell användning eller Minnesoptimerad. Kontrollera att källservern finns på någon av dessa prisnivåer.
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 MariaDB-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.
Kommentar
Om du inte har konfigurerat någon lagringsavisering på dina servrar rekommenderar vi att du gör det. Aviseringen informerar dig när en server närmar sig sin lagringsgräns, vilket påverkar replikeringen.
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 hjälp av dess värdnamn och ett giltigt användarkonto, precis som på en vanlig Azure Database for MariaDB-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.mariadb.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 MariaDB 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 MariaDB: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.
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 automatisk 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.
Eftersom replikeringen är asynkron finns det fördröjning mellan källan och repliken. Mängden fördröjning kan påverkas av ett antal 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 visar 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äxlar till en replik
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 från den primära servern. 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.
Peka programmet på repliken (tidigare).
Varje server har en unik anslutningssträng. Uppdatera programmet så att det pekar på (tidigare) repliken i stället för den primära.
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 ovan.
Beaktanden och begränsningar
Prisnivåer
Läsrepliker är för närvarande endast tillgängliga på prisnivåerna Generell användning och Minnesoptimerad.
Kommentar
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 skrivskyddad replik skapas som en ny Azure Database for MariaDB-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 den primära. När en replik har skapats kan flera inställningar ändras oberoende av källservern: beräkningsgenerering, virtuella kärnor, lagring, kvarhållningsperiod för säkerhetskopiering och MariaDB-motorversion. Prisnivån kan också ändras oberoende av varandra, förutom till eller från Basic-nivån.
Viktigt!
Uppdatera replikkonfigurationen till samma eller högre värden innan en källserverkonfiguration uppdateras till nya värden. Den här åtgärden säkerställer att repliken kan hålla jämna steg med alla ändringar som görs i den primära.
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:
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å den primära och återskapar repliker.
Ö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 MariaDB-replikeringstekniken.
- Kontrollera att källservertabellerna har primära nycklar. Brist på primära nycklar kan leda till replikeringsfördröjning mellan källan och replikerna.