Översikt över redundansgrupper och metodtips – Azure SQL Managed Instance

  • Artikel

Gäller för:Azure SQL Managed Instance

Med funktionen redundansgrupper kan du hantera replikering och redundans för alla användardatabaser i en hanterad instans till en annan Azure-region. Den här artikeln innehåller en översikt över funktionen för redundansgrupper med metodtips och rekommendationer för att använda den med Azure SQL Managed Instance.

Kom igång med funktionen genom att läsa Konfigurera en redundansgrupp för Azure SQL Managed Instance.

Översikt

Med funktionen redundansgrupper kan du hantera replikering och redundans för användardatabaser i en hanterad instans till en hanterad instans i en annan Azure-region. Redundansgrupper är utformade för att förenkla distribution och hantering av geo-replikerade databaser i stor skala.

Mer information finns i Hög tillgänglighet för Azure SQL Managed Instance. Information om RPO och RTO för geo-redundans finns i Översikt över affärskontinuitet.

Omdirigering av slutpunkt

Redundansgrupper tillhandahåller skrivskyddade och skrivskyddade lyssnarens slutpunkter som förblir oförändrade under geo-redundansväxlingar. Du behöver inte ändra anslutningssträng för ditt program efter en geo-redundans eftersom anslutningar automatiskt dirigeras till den aktuella primära. En geo-redundansväxlar alla sekundära databaser i gruppen till den primära rollen. När geo-redundans har slutförts uppdateras DNS-posten automatiskt för att omdirigera slutpunkterna till den nya regionen.

Avlasta skrivskyddade arbetsbelastningar

Om du vill minska trafiken till dina primära databaser kan du också använda de sekundära databaserna i en redundansgrupp för att avlasta skrivskyddade arbetsbelastningar. Använd den skrivskyddade lyssnaren för att dirigera skrivskyddad trafik till en läsbar sekundär databas.

Återställa ett program

För att uppnå fullständig affärskontinuitet är det bara en del av lösningen att lägga till regional databasredundans. Återställning av ett program (tjänst) från slutpunkt till slutpunkt efter ett oåterkalleligt fel kräver återställning av alla komponenter som utgör tjänsten och alla beroende tjänster. Exempel på dessa komponenter är klientprogramvaran (till exempel en webbläsare med ett anpassat JavaScript), webbklientdelar, lagring och DNS. Det är viktigt att alla komponenter är motståndskraftiga mot samma fel och blir tillgängliga inom programmets mål för återställningstid (RTO). Därför måste du identifiera alla beroende tjänster och förstå de garantier och funktioner som de tillhandahåller. Sedan måste du vidta lämpliga åtgärder för att säkerställa att tjänsten fungerar under redundansväxlingen av de tjänster som den är beroende av.

Redundansprincip

Redundansgrupper stöder två redundansprinciper:

  • Kundhanterad (rekommenderas) – Kunder kan utföra en redundansväxling av en grupp när de märker ett oväntat avbrott som påverkar en eller flera databaser i redundansgruppen. När du använder kommandoradsverktyg som PowerShell, Azure CLI eller Rest API är manualvärdet för redundansprincipen för kundhanterade .
  • Microsoft hanterad – I händelse av ett omfattande avbrott som påverkar en primär region initierar Microsoft redundans av alla berörda redundansgrupper som har sin redundansprincip konfigurerad att vara Microsoft-hanterad. Microsofts hanterade redundansväxling initieras inte för enskilda redundansgrupper eller en delmängd av redundansgrupper i en region. När du använder kommandoradsverktyg som PowerShell, Azure CLI eller Rest API är automaticvärdet för redundansprincipen för Microsoft-hanterad .

Varje redundansprincip har en unik uppsättning användningsfall och motsvarande förväntningar på redundansomfånget och dataförlusten, som följande tabell sammanfattar:

Redundansprincip Redundansomfång Användningsfall Potentiell dataförlust
Kundhanterad
(Rekommenderas)		 Redundansgrupper En eller flera databaser i en redundansgrupp påverkas av ett avbrott och blir otillgängliga. Du kan välja att redundansväxla. Ja
Hanterad av Microsoft Alla redundansgrupper i regionen Ett omfattande avbrott i ett datacenter, en tillgänglighetszon eller en region orsakar otillgänglighet för databaser och Microsoft Azure SQL-tjänstteamet bestämmer sig för att utlösa en tvingad redundansväxling.
Använd endast det här alternativet om du vill delegera ansvaret för haveriberedskap till Microsoft och programmet är tolerant mot RTO (stilleståndstid) på minst en timme eller mer.		 Ja

Kundhanterad

I sällsynta fall räcker inte den inbyggda tillgängligheten eller hög tillgänglighet för att minska ett avbrott, och dina databaser i en redundansgrupp kan vara otillgängliga under en tid som inte är acceptabel för serviceavtalet (SLA) för program som använder databaserna. Databaser kan inte vara tillgängliga på grund av ett lokaliserat problem som påverkar bara några få databaser, eller på datacenter-, tillgänglighetszon- eller regionnivå. I något av dessa fall kan du initiera en tvingad redundansväxling för att återställa affärskontinuiteten.

Att ställa in redundanspolicyn på kundhanterad rekommenderas starkt, eftersom du får kontroll över när du ska initiera en redundansväxling och återställa affärskontinuitet. Du kan initiera en redundansväxling när du märker ett oväntat avbrott som påverkar en eller flera databaser i redundansgruppen.

Hanterad av Microsoft

Med en Microsoft-hanterad redundansprincip delegeras ansvaret för haveriberedskap till Azure SQL-tjänsten. För att Azure SQL-tjänsten ska kunna initiera en tvingad redundansväxling måste följande villkor uppfyllas:

  • Avbrott på datacenter-, tillgänglighetszon- eller regionnivå som orsakas av en naturkatastrof, konfigurationsändringar, programvarubuggar eller maskinvarukomponentfel och många databaser i regionen påverkas.
  • Respitperioden har upphört att gälla. Eftersom verifieringen av omfattningen av och mildrandet beror på mänskliga åtgärder, kan respitperioden inte anges under en timme.

När dessa villkor uppfylls initierar Azure SQL-tjänsten framtvingade redundansväxlingar för alla redundansgrupper i regionen som har redundansprincipen inställd på Microsoft hanterad.

Ange redundansprincipen till Microsoft hanterad endast när:

  • Du vill delegera ansvaret för haveriberedskap till Azure SQL-tjänsten.
  • Programmet är tolerant mot att databasen inte är tillgänglig i minst en timme eller mer.
  • Det är acceptabelt att utlösa framtvingade redundansväxlingar en tid efter att respitperioden upphör att gälla eftersom den faktiska tiden för den framtvingade redundansväxlingen kan variera avsevärt.
  • Det är acceptabelt att alla databaser i redundansgruppen redundansväxlar, oavsett zonredundanskonfiguration eller tillgänglighetsstatus. Även om databaser som konfigurerats för zonredundans är motståndskraftiga mot zonfel och kanske inte påverkas av ett avbrott, kommer de fortfarande att redundansväxlas om de ingår i en redundansgrupp med en Microsoft-hanterad redundansprincip.
  • Det är acceptabelt att ha framtvingade redundansväxlingar av databaser i redundansgruppen utan att ta hänsyn till programmets beroende av andra Azure-tjänster eller komponenter som används av programmet, vilket kan orsaka prestandaförsämring eller otillgänglighet för programmet.
  • Det är acceptabelt att ådra sig en okänd mängd dataförlust eftersom den exakta tiden för tvingad redundans inte kan kontrolleras och ignorerar synkroniseringsstatusen för de sekundära databaserna.
  • Alla primära och sekundära databaser i redundansgruppen har samma tjänstnivå, beräkningsnivå (etablerad eller serverlös) och beräkningsstorlek (DTU:er eller virtuella kärnor). Om servicenivåmålet (SLO) för alla databaser i en redundansgrupp inte matchar uppdateras redundanspolicyn så småningom från Microsoft Managed to Customer Managed by Azure SQL Service.

När en redundansväxling utlöses av Microsoft läggs en post för åtgärdsnamnet Redundans för Azure SQL-redundans till i Azure Monitor-aktivitetsloggen. Posten innehåller namnet på redundansgruppen under Resurs, och Händelsen som initierades av visar ett enda bindestreck (-) som anger att redundansväxlingen initierades av Microsoft. Den här informationen finns också på sidan Aktivitetslogg för den nya primära servern eller instansen i Azure-portalen.

Terminologi och funktioner

  • Redundansgrupp (FOG)

    Med en redundansgrupp kan alla användardatabaser i en hanterad instans redundansväxla som en enhet till en annan Azure-region om den primära hanterade instansen blir otillgänglig på grund av ett avbrott i den primära regionen. Eftersom redundansgrupper för SQL Managed Instance innehåller alla användardatabaser i instansen kan endast en redundansgrupp konfigureras på en instans.

    Viktigt!

    Namnet på redundansgruppen måste vara globalt unikt inom domänen .database.windows.net.

  • Primär kontakt

    Den hanterade instansen som är värd för de primära databaserna i redundansgruppen.

  • Sekundära

    Den hanterade instansen som är värd för de sekundära databaserna i redundansgruppen. Den sekundära kan inte finnas i samma Azure-region som den primära.

    Viktigt!

    • Om en databas innehåller minnesinterna OLTP-objekt måste den primära och sekundära geo-replikinstansen ha matchande tjänstnivåer, eftersom minnesinterna OLTP-objekt finns i minnet. En lägre tjänstnivå på geo-replikinstansen kan leda till problem med minnesbrist. Om detta inträffar kan den sekundära repliken misslyckas med att återställa databasen, vilket orsakar otillgänglighet för den sekundära databasen tillsammans med minnesinterna OLTP-objekt på den geo-sekundära. Detta kan i sin tur också leda till att redundans misslyckas. Undvik detta genom att se till att tjänstnivån för den geo-sekundära instansen matchar den primära databasens. Uppgraderingar på tjänstnivå kan vara datastorleksåtgärder och kan ta ett tag att slutföra.

  • Redundansväxling (ingen dataförlust)

    Redundans utför fullständig datasynkronisering mellan primära och sekundära databaser innan den sekundära växlar till den primära rollen. Detta garanterar ingen dataförlust. Redundans är bara möjligt när den primära är tillgänglig. Redundans används i följande scenarier:

    • Utföra haveriberedskapstest (DR) i produktion när dataförlust inte är acceptabelt
    • Flytta arbetsbelastningen till en annan region
    • Returnera arbetsbelastningen till den primära regionen efter att avbrottet har åtgärdats (återställning efter fel)

  • Tvingad redundansväxling (potentiell dataförlust)

    Tvingad redundans växlar omedelbart den sekundära till den primära rollen utan att vänta på att de senaste ändringarna ska spridas från den primära. Den här åtgärden kan leda till potentiell dataförlust. Tvingad redundans används som en återställningsmetod vid avbrott när den primära inte är tillgänglig. När avbrotten har åtgärdats återansluter den gamla primära automatiskt och blir en ny sekundär. En redundansväxling kan köras för återställning efter fel, vilket returnerar replikerna till deras ursprungliga primära och sekundära roller.

  • Respitperiod med dataförlust

    Eftersom data replikeras till den sekundära med asynkron replikering kan tvingad redundansväxling av grupper med Microsofts hanterade redundansprinciper leda till dataförlust. Du kan anpassa redundanspolicyn så att den återspeglar programmets tolerans mot dataförlust. Genom att GracePeriodWithDataLossHourskonfigurera kan du styra hur länge Azure SQL-tjänsten väntar innan du påbörjar en tvingad redundansväxling, vilket kan leda till dataförlust.

  • DNS-zon

    Ett unikt ID som genereras automatiskt när en ny SQL Managed Instance skapas. Ett SAN-certifikat (Multi-Domain) för den här instansen etableras för att autentisera klientanslutningarna till alla instanser i samma DNS-zon. De två hanterade instanserna i samma redundansgrupp måste dela DNS-zonen.

  • Läs/skriv-lyssnare för redundansgrupp

    En DNS CNAME-post som pekar på den aktuella primära posten. Den skapas automatiskt när redundansgruppen skapas och gör att läs-och skriv-arbetsbelastningen transparent kan återansluta till den primära när den primära ändras efter redundansväxlingen. När redundansgruppen skapas på en SQL Managed Instance skapas DNS CNAME-posten för lyssnarens URL som <fog-name>.<zone_id>.database.windows.net.

  • Skrivskyddad lyssnare för redundansgrupp

    En DNS CNAME-post som pekar på den aktuella sekundära posten. Den skapas automatiskt när redundansgruppen skapas och tillåter att den skrivskyddade SQL-arbetsbelastningen transparent ansluter till den sekundära när den sekundära ändras efter redundansväxlingen. När redundansgruppen skapas på en SQL Managed Instance skapas DNS CNAME-posten för lyssnarens URL som <fog-name>.secondary.<zone_id>.database.windows.net. Som standard inaktiveras redundansväxling av den skrivskyddade lyssnaren eftersom det säkerställer att prestanda för den primära inte påverkas när den sekundära är offline. Men det innebär också att skrivskyddade sessioner inte kan ansluta förrän den sekundära har återställts. Om du inte kan tolerera stilleståndstid för skrivskyddade sessioner och kan använda den primära för både skrivskyddad och skrivskyddad trafik på bekostnad av den potentiella prestandaförsämringen av den primära, kan du aktivera redundans för den skrivskyddade lyssnaren AllowReadOnlyFailoverToPrimary genom att konfigurera egenskapen. I så fall omdirigeras den skrivskyddade trafiken automatiskt till den primära om den sekundära inte är tillgänglig.

    Kommentar

    Egenskapen AllowReadOnlyFailoverToPrimary har endast effekt om Microsofts hanterade redundansprincip är aktiverad och en tvingad redundans har utlösts. I så fall, om egenskapen är inställd på True, kommer den nya primären att hantera både skrivskyddade och skrivskyddade sessioner.

Arkitektur för redundanskluster

Redundansgruppen måste konfigureras på den primära instansen och ansluter den till den sekundära instansen i en annan Azure-region. Alla användardatabaser i instansen replikeras till den sekundära instansen. Systemdatabaser som master och msdb replikeras inte.

Följande diagram illustrerar en typisk konfiguration av ett geo-redundant molnprogram med hjälp av hanterad instans och redundansgrupp:

diagram of a failover group for Azure SQL Managed Instance.

Om ditt program använder SQL Managed Instance som datanivå följer du de allmänna riktlinjer och metodtips som beskrivs i den här artikeln när du utformar för affärskontinuitet.

Skapa den geo-sekundära instansen

För att säkerställa en oavbruten anslutning till den primära SQL Managed Instance efter redundansväxlingen måste både de primära och sekundära instanserna finnas i samma DNS-zon. Det garanterar att samma SAN-certifikat (multi-domain) kan användas för att autentisera klientanslutningar till någon av de två instanserna i redundansgruppen. När ditt program är redo för produktionsdistribution skapar du en sekundär SQL Managed Instance i en annan region och ser till att den delar DNS-zonen med den primära SQL Managed Instance. Du kan göra det genom att ange en valfri parameter när du skapar den. Om du använder PowerShell eller REST-API:et är DNSZonePartnernamnet på den valfria parametern . Namnet på motsvarande valfria fält i Azure-portalen är Primär hanterad instans.

Viktigt!

Den första hanterade instansen som skapas i undernätet avgör DNS-zonen för alla efterföljande instanser i samma undernät. Det innebär att två instanser från samma undernät inte kan tillhöra olika DNS-zoner.

Mer information om hur du skapar den sekundära SQL Managed Instance i samma DNS-zon som den primära instansen finns i Konfigurera en redundansgrupp för Azure SQL Managed Instance.

Använda länkade regioner

Distribuera båda hanterade instanserna till länkade regioner av prestandaskäl. SQL Managed Instance-redundansgrupper i länkade regioner har bättre prestanda jämfört med olänkade regioner.

Azure SQL Managed Instance följer en säker distributionspraxis där azure-kopplade regioner vanligtvis inte distribueras till på samma gång. Det går dock inte att förutsäga vilken region som ska uppgraderas först, så distributionsordningen är inte garanterad. Ibland uppgraderas den primära instansen först och ibland uppgraderas den sekundära instansen först.

I situationer där Azure SQL Managed Instance ingår i en redundansgrupp och instanserna i gruppen inte finns i azure-kopplade regioner väljer du olika underhållsfönsterscheman för din primära och sekundära databas. Du kan till exempel välja ett veckodagunderhållsfönster för din geo-sekundära databas och ett helgunderhållsfönster för din geo-primära databas.

Aktivera och optimera trafikflödet för geo-replikering mellan instanserna

Anslut mellan det virtuella nätverkets undernät som är värd för den primära och sekundära instansen måste upprättas och underhållas för avbrott i trafikflödet för geo-replikering. Det finns flera sätt att tillhandahålla anslutning mellan de instanser som du kan välja mellan baserat på din nätverkstopologi och principer:

Global peering för virtuella nätverk (VNet-peering) är det rekommenderade sättet att upprätta anslutning mellan två instanser i en redundansgrupp. Det ger en privat anslutning med låg svarstid och hög bandbredd mellan de peerkopplade virtuella nätverken med hjälp av Microsofts stamnätsinfrastruktur. Inget offentligt Internet, gatewayer eller ytterligare kryptering krävs i kommunikationen mellan de peerkopplade virtuella nätverken.

Inledande seeding

När du upprättar en redundansgrupp mellan hanterade instanser finns det en inledande seeding-fas innan datareplikeringen startar. Den inledande seedningsfasen är den längsta och dyraste delen av åtgärden. När den första seedingen har slutförts synkroniseras data och endast efterföljande dataändringar replikeras. Den tid det tar för den inledande seedningen att slutföras beror på storleken på data, antalet replikerade databaser, arbetsbelastningsintensiteten på de primära databaserna och hastigheten på länken mellan de virtuella nätverk som är värdar för den primära och sekundära instansen som främst beror på hur anslutningen upprättas. Under normala omständigheter, och när anslutningen upprättas med rekommenderad global peering för virtuella nätverk, är starthastigheten upp till 360 GB i timmen för SQL Managed Instance. Seeding utförs för en batch med användardatabaser parallellt – inte nödvändigtvis för alla databaser samtidigt. Flera batchar kan behövas om det finns många databaser på instansen.

Om hastigheten för länken mellan de två instanserna är långsammare än vad som är nödvändigt påverkas sannolikt tiden till starttiden märkbart. Du kan använda angiven seedinghastighet, antal databaser, total datastorlek och länkhastigheten för att uppskatta hur lång tid den inledande seeding-fasen tar innan datareplikeringen startar. För en enskild databas på 100 GB skulle den inledande startfasen till exempel ta cirka 1,2 timmar om länken kan push-överföra 84 GB per timme och om det inte finns några andra databaser som seedas. Om länken bara kan överföra 10 GB per timme kan det ta cirka 10 timmar att skicka en databas på 100 GB. Om det finns flera databaser att replikera körs seeding parallellt, och när den kombineras med en långsam länkhastighet kan den inledande seeding-fasen ta betydligt längre tid, särskilt om parallell seeding av data från alla databaser överskrider den tillgängliga länkbandbredden.

Viktigt!

I händelse av en extremt låg hastighet eller upptagen länk som gör att den inledande seeding-fasen tar dagar kan skapandet av en redundansgrupp överskrida tidsgränsen. Processen för att skapa avbryts automatiskt efter 6 dagar.

Hantera geo-redundans till en geo-sekundär instans

Redundansgruppen hanterar geo-redundans för alla databaser på den primära hanterade instansen. När en grupp skapas geo-replikeras varje databas i instansen automatiskt till den geo-sekundära instansen. Du kan inte använda redundansgrupper för att initiera en partiell redundansväxling av en delmängd databaser.

Viktigt!

Om en databas tas bort på den primära hanterade instansen tas den också bort automatiskt på den geo-sekundära hanterade instansen.

Använda läs- och skrivlyssnaren (primär MI)

För skrivskyddade arbetsbelastningar använder du <fog-name>.zone_id.database.windows.net som servernamn. Anslut ions dirigeras automatiskt till den primära. Det här namnet ändras inte efter redundansväxlingen. Geo-redundans innebär uppdatering av DNS-posten, så de nya klientanslutningarna dirigeras till den nya primära först efter att klientens DNS-cache har uppdaterats. Eftersom den sekundära instansen delar DNS-zonen med den primära kan klientprogrammet återansluta till den med samma SAN-certifikat på serversidan. De befintliga klientanslutningarna måste avslutas och sedan återskapas för att dirigeras till den nya primära. Det går inte att nå lyssnaren och den skrivskyddade lyssnaren via den offentliga slutpunkten för den hanterade instansen.

Använd den skrivskyddade lyssnaren (sekundär MI)

Om du har logiskt isolerade skrivskyddade arbetsbelastningar som är toleranta mot datafördröjning kan du köra dem på den geo-sekundära. Om du vill ansluta direkt till den geo-sekundära använder du <fog-name>.secondary.<zone_id>.database.windows.net som servernamn.

På den Affärskritisk nivån stöder SQL Managed Instance användning av skrivskyddade repliker för att avlasta skrivskyddade frågearbetsbelastningar med hjälp av parametern ApplicationIntent=ReadOnly i anslutningssträng. När du har konfigurerat en geo-replikerad sekundär kan du använda den här funktionen för att ansluta till antingen en skrivskyddad replik på den primära platsen eller på den geo-replikerade platsen:

  • Om du vill ansluta till en skrivskyddad replik på den primära platsen använder du ApplicationIntent=ReadOnly och <fog-name>.<zone_id>.database.windows.net.
  • Om du vill ansluta till en skrivskyddad replik på den sekundära platsen använder du ApplicationIntent=ReadOnly och <fog-name>.secondary.<zone_id>.database.windows.net.

Det går inte att nå lyssnaren och den skrivskyddade lyssnaren via den offentliga slutpunkten för den hanterade instansen.

Potentiell prestandaförsämring efter redundansväxling

Ett typiskt Azure-program använder flera Azure-tjänster och består av flera komponenter. Geo-redundans för gruppen utlöses baserat på tillståndet för enbart Azure SQL-komponenterna. Andra Azure-tjänster i den primära regionen kanske inte påverkas av avbrotten och deras komponenter kan fortfarande vara tillgängliga i den regionen. När de primära databaserna växlar till den sekundära regionen kan svarstiden mellan de beroende komponenterna öka. Kontrollera redundansen för alla programmets komponenter i den sekundära regionen och redundansväxla programkomponenter tillsammans med databasen så att programmets prestanda inte påverkas av längre svarstider mellan regioner.

Potentiell dataförlust efter tvingad redundans

Om ett avbrott inträffar i den primära regionen kanske de senaste transaktionerna inte har replikerats till den geo-sekundära och det kan uppstå dataförlust om en tvingad redundans utförs.

DNS-uppdatering

DNS-uppdateringen av läs- och skrivlyssning sker omedelbart efter att redundansväxlingen har initierats. Den här åtgärden resulterar inte i dataförlust. Det kan dock ta upp till 5 minuter att byta databasroller under normala förhållanden. Tills den har slutförts är vissa databaser i den nya primära instansen fortfarande skrivskyddade. Om en redundansväxling initieras med PowerShell är åtgärden för att växla den primära replikrollen synkron. Om det initieras med hjälp av Azure-portalen anger användargränssnittet slutförandestatus. Om det initieras med hjälp av REST API använder du Azure Resource Manager-avsökningsmekanismen som standard för att övervaka slutförandet.

Viktigt!

Använd manuell planerad redundans för att flytta den primära tillbaka till den ursprungliga platsen när det avbrott som orsakade geo-redundansen har åtgärdats.

Spara kostnader med en licensfri DR-replik

Du kan spara på SQL Server-licenskostnader genom att konfigurera att din sekundära hanterade instans endast ska användas för haveriberedskap (DR). Information om hur du konfigurerar detta finns i Konfigurera en licensfri standby-replik för Azure SQL Managed Instance.

Så länge den sekundära instansen inte används för läsarbetsbelastningar ger Microsoft dig ett kostnadsfritt antal virtuella kärnor som matchar den primära instansen. Du debiteras fortfarande för beräkning och lagring som används av den sekundära instansen. Redundansgrupper stöder endast en replik – repliken måste antingen vara en läsbar replik eller vara en dr-only-replik.

Aktivera scenarier som är beroende av objekt från systemdatabaserna

Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Om du vill möjliggöra scenarier som är beroende av objekt från systemdatabaserna ska du skapa samma objekt i den sekundära instansen och hålla dem synkroniserade med den primära instansen.

Om du till exempel planerar att använda samma inloggningar på den sekundära instansen måste du skapa dem med samma SID.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Mer information finns i Replikering av inloggningar och agentjobb.

Synkronisera instansegenskaper och instanser av kvarhållningsprinciper

Instanser i en redundansgrupp förblir separata Azure-resurser och inga ändringar som görs i konfigurationen av den primära instansen replikeras automatiskt till den sekundära instansen. Se till att utföra alla relevanta ändringar både på den primära och sekundära instansen. Om du till exempel ändrar redundans för lagring av säkerhetskopior eller långsiktig kvarhållningsprincip för säkerhetskopiering på den primära instansen måste du även ändra den på den sekundära instansen.

Skala instanser

Du kan skala upp eller skala ned den primära och sekundära instansen till en annan beräkningsstorlek inom samma tjänstnivå eller till en annan tjänstnivå. När du skalar upp inom samma tjänstnivå rekommenderar vi att du skalar upp den geo-sekundära först och sedan skalar upp den primära. När du skalar ned inom samma tjänstnivå ändrar du ordningen: skala ned den primära först och skala sedan ned den sekundära. När du skalar instansen till en annan tjänstnivå framtvingas den här rekommendationen. Åtgärdssekvensen tillämpas vid skalning av tjänstnivån och virtuella kärnor samt lagring.

Den här sekvensen rekommenderas särskilt för att undvika problemet där den geo-sekundära instansen med en lägre SKU blir överbelastad och måste dirigeras om under en uppgradering eller nedgradering.

Kommentar

Det finns ett känt problem som kan påverka tillgängligheten för den instans som skalas med hjälp av den associerade redundansgruppens lyssnare.

Förhindra förlust av kritiska data

På grund av den långa svarstiden för nätverk i stora områden använder geo-replikering en asynkron replikeringsmekanism. Asynkron replikering gör risken för dataförlust oundviklig om den primära replikeringen misslyckas. För att skydda kritiska transaktioner mot dataförlust kan en programutvecklare anropa den sp_wait_for_database_copy_sync lagrade proceduren omedelbart efter att transaktionen har genomförts. Anrop sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senast checkade transaktionen har överförts och härdats i transaktionsloggen för den sekundära databasen. Det väntar dock inte på att de överförda transaktionerna ska spelas upp igen (görs om) på den sekundära. sp_wait_for_database_copy_sync är begränsad till en specifik geo-replikeringslänk. Alla användare med anslutningsrättigheter till den primära databasen kan anropa den här proceduren.

För att förhindra dataförlust under användarinitierad, planerad geo-redundans, replikering automatiskt och tillfälligt ändringar i synkron replikering, utför sedan en redundansväxling. Replikeringen återgår sedan till asynkront läge när geo-redundansväxlingen är klar.

Kommentar

sp_wait_for_database_copy_sync förhindrar dataförlust efter geo-redundans för specifika transaktioner, men garanterar inte fullständig synkronisering för läsåtkomst. Fördröjningen som orsakas av ett sp_wait_for_database_copy_sync proceduranrop kan vara betydande och beror på storleken på den ännu inte överförda transaktionsloggen på den primära vid tidpunkten för anropet.

Status för redundansgrupp

Redundansgruppen rapporterar sin status som beskriver datareplikeringens aktuella tillstånd:

  • Seeding – Inledande seeding sker när redundansgruppen har skapats tills alla användardatabaser initieras på den sekundära instansen. Redundansväxlingsprocessen kan inte initieras när redundansgruppen är i statusen Seeding, eftersom användardatabaser inte har kopierats till den sekundära instansen ännu.
  • Synkronisering – den vanliga statusen för redundansgruppen. Det innebär att dataändringar på den primära instansen replikeras asynkront till den sekundära instansen. Den här statusen garanterar inte att data synkroniseras fullständigt varje gång. Det kan finnas dataändringar från den primära som fortfarande ska replikeras till den sekundära på grund av replikeringsprocessens asynkrona karaktär mellan instanser i redundansgruppen. Både automatiska och manuella redundansväxlingar kan initieras medan redundansgruppen har statusen Synkronisering.
  • Redundans pågår – den här statusen anger att antingen automatiskt eller manuellt initierad redundans pågår. Inga ändringar i redundansgruppen eller ytterligare redundansväxlingar kan initieras medan redundansgruppen har den här statusen.

Återställning efter fel

När redundansgrupper konfigureras med en Microsoft-hanterad redundansprincip initieras tvingad redundans till den geo-sekundära servern under ett katastrofscenario enligt den definierade respitperioden. Återställning efter fel till den gamla primära måste initieras manuellt.

Redundansgrupper med transaktionsreplikering

Användning av transaktionsreplikering med instanser som finns i en redundansgrupp stöds. Men om du konfigurerar replikering innan du lägger till din SQL-hanterade instans i en redundansgrupp pausar replikeringen när du börjar skapa redundansgruppen och replikeringsövervakaren visar statusen Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replikeringen återupptas när redundansgruppen har skapats.

Om en utgivare eller distributör av sql-hanterad instans finns i en redundansgrupp måste SQL-administratören för den hanterade instansen rensa alla publikationer på den gamla primära och konfigurera om dem på den nya primära när en redundansväxling har inträffat. Granska guiden för transaktionsreplikering för de steg av aktiviteter som behövs i det här scenariot.

Behörigheter, begränsningar och krav

Gå igenom guiden konfigurera redundansgrupp för en lista över behörigheter, begränsningar och krav innan du fortsätter att konfigurera redundansgruppen.

Hantera redundansgrupper programmatiskt

Redundansgrupper kan även hanteras programmatiskt med hjälp av Azure PowerShell, Azure CLI och REST API. Läs mer i Konfigurera redundansgrupp .

Relaterat innehåll