Skrivskyddad replik i Azure Database for MariaDB

  • Artikel
  • 8 minuter för att läsa

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 mariaDB-motorns positionsbaserade replikeringsteknik baserad på binär loggfil (binlog) med globalt transaktions-ID (GTID). Mer information om binlog-replikering finns i översikten över binlog replication.

Repliker är nya servrar som du hanterar på liknande sätt som vanliga Azure Database for MariaDB servrar. För varje skrivskyddad replik 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 MariaDB-replikeringsdokumentationen.

Anteckning

Den här artikeln innehåller referenser till termen slave, 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 skrivskyddade replik

Funktionen för skrivskyddade repliker hjälper 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 repliken.

Ett vanligt scenario är att BI och analytiska arbetsbelastningar använder den skrivskyddade repliken som datakälla för rapportering.

Eftersom repliker är skrivskyddade minskar de inte skrivkapaciteten direkt på den primära repliken. Den här funktionen är inte riktad mot skrivintensiva arbetsbelastningar.

Funktionen för skrivskyddade repliker använder asynkron replikering. Funktionen är inte avsedd för scenarier med synkron replikering. Det blir en mätbar fördröjning mellan källan och repliken. Data på repliken blir slutligen konsekventa med data på den primära repliken. 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 skrivskyddade replik i en annan region än källservern. Replikering mellan regioner kan vara användbart för scenarier som planering av haveriberedskap eller för att föra data närmare dina användare.

Du kan ha en källserver i valfri Azure Database for MariaDB region. En källserver kan ha en replik i den parkopplade regionen eller de universella replikregionerna. Bilden nedan visar vilka replikregioner som är tillgängliga beroende på din källregion.

Skrivskyddade replikregioner

Universella replikregioner

Du kan skapa en skrivskyddade replik 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, Asien, östra, USA, östra, USA, östra 2, Japan, östra, Japan, västra, Sydkorea, centrala, Sydkorea, södra, USA, norra centrala, Europa, norra, 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-parkopplade regionen för källservern. Om du inte känner till paren i din region kan du läsa mer i artikeln om parkopplade Azure-regioner.

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

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

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

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

Skapa en replik

Viktigt

Funktionen skrivskyddad replik är endast tillgänglig för Azure Database for MariaDB-servrar i Generell användning eller minnesoptimerade prisnivåer. Se till att källservern är 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 Azure Database for MariaDB en tom 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.

Anteckning

Om du inte har en lagringsavisering konfigurerad på dina servrar rekommenderar vi att du gör det. Aviseringen informerar dig när en server närmar sig lagringsgränsen, vilket påverkar replikeringen.

Lär dig hur du skapar en skrivskyddade replik i Azure Portal.

Anslut till en replik

När en replik skapas ärver den källserverns brandväggsregler. 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 de skrivskyddade replikerna. 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örsnamnet myadmin kan du ansluta till repliken med mysql CLI:

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

Ange lösenordet för användarkontot i prompten.

Övervaka replikering

Azure Database for MariaDB 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 seconds_behind_master med hjälp av måttet som är tillgängligt i MariaDB-kommandot. SHOW SLAVE STATUS

Ställ in 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 skrivskyddad replik blir repliken en fristående server. Data på den fristående servern är de data som var tillgängliga på repliken när kommandot för att stoppa replikering 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 den tidigare källan och andra repliker. Det finns ingen automatisk redundans 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 skrivskyddade replik ser du till att repliken har alla data som du behöver.

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

Redundans

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

Eftersom replikeringen är asynkron finns det en fördröjning mellan källan och repliken. Fördröjningen kan påverkas av ett antal faktorer som t.ex. 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öjning 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 återspelade transaktionen. Vi rekommenderar att du identifierar den genomsnittliga fördröjningen genom att observera replikfördröjning under en viss tidsperiod. Du kan ställa in en avisering för replikfördröjning, så att du kan vidta åtgärder om den hamnar utanför det förväntade intervallet.

Tips

Om du redundansar till repliken visar fördröjningen vid den tidpunkt då du länkar bort repliken från källan hur mycket data som går förlorade.

När du har bestämt dig för att växla över 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 den primära replikservern. När du har initierat stoppreplikeringen tar det vanligtvis cirka 2 minuter att slutföra backend-processen. Se avsnittet om att stoppa replikering i den här artikeln för att förstå konsekvenserna av den här åtgärden.

  2. Peka ditt program till den (tidigare) repliken.

    Varje server har en unik anslutningssträng. Uppdatera programmet så att det pekar på repliken (tidigare) i stället för den primära repliken.

När programmet har bearbetat läsningar och skrivningar har du slutfört redundansen. Mängden avbrottstid som programmet upplever beror på när du identifierar ett problem och slutför steg 1 och 2 ovan.

Överväganden och begränsningar

Prisnivåer

Skrivskyddade repliker är för närvarande endast tillgängliga Generell användning och minnesoptimerade prisnivåer.

Anteckning

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 startas källan först om för att förbereda sig för replikering. Ta detta i beaktande och utför dessa åtgärder under en period med låg belastning.

Nya repliker

En skrivskyddad replik skapas som en ny Azure Database for MariaDB server. En befintlig server kan inte göras till en replik. Du kan inte skapa en replik av en annan skrivskyddade replik.

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äkerhetskopior 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 koll på alla ändringar som görs i den primära repliken.

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 skrivskyddad replik 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 skrivskyddade 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 skrivskyddade repliker. Du kan bara ansluta till en skrivskyddade replik med 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 parametrarna ovan på källservern tar du bort replikservrarna, uppdaterar parametervärdet på den primära servern och återskapar replikerna.

Övrigt

  • Det går inte att skapa en replik av en replik.
  • Minnes in memory-tabeller kan göra att repliker blir osynkronisering. Det här är en begränsning i MariaDB-replikeringstekniken.
  • Se till att källservertabellerna har primära nycklar. Brist på primära nycklar kan resultera i replikeringsfördröjning mellan källan och replikerna.

Nästa steg