Dela via

Konfigurera en redundansgrupp för Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

I den här artikeln lär du dig hur du konfigurerar en redundansgrupp för Azure SQL Managed Instance med hjälp av Azure-portalen och Azure PowerShell.

För ett fullständigt PowerShell-skript för att skapa båda instanserna inom en redundansgrupp, se Lägg till instans i en redundansgrupp med PowerShell.

Förutsättningar

Om du vill konfigurera en redundansgrupp bör du redan ha rätt behörigheter och en SQL-hanterad instans som du tänker använda som primär. Gå till Skapa instans för att komma igång.

Se till att granska begränsningarna innan du skapar den sekundära instansen och redundansgruppen.

Konfigurationskrav

Tänk på följande krav för att konfigurera en redundansgrupp mellan en primär och sekundär SQL Managed Instance:

  • Den sekundära hanterade instansen måste vara tom, utan några användardatabaser.
  • Konfigurationen av din primära och sekundära instans bör vara densamma för att säkerställa att den sekundära instansen kan bearbeta ändringar som replikeras från den primära instansen på ett hållbart sätt, inklusive under perioder med hög aktivitet. Detta omfattar beräkningsstorlek, lagringsstorlek och tjänstnivå.
  • IP-adressintervallet för det virtuella nätverket för den primära instansen får inte överlappa adressintervallet för det virtuella nätverket för den sekundära hanterade instansen eller något annat virtuellt nätverk som är peerkopplat med det primära eller sekundära virtuella nätverket.
  • Båda instanserna måste finnas i samma DNS-zon. När du skapar den sekundära hanterade instansen måste du ange den primära instansens DNS-zon-ID. Om du inte gör det genereras zon-ID:t som en slumpmässig sträng när den första instansen skapas i varje virtuellt nätverk och samma ID tilldelas till alla andra instanser i samma undernät. När DNS-zonen har tilldelats kan du inte ändra den.
  • NSG-regler (Network Security Groups) för undernäten för båda instanserna måste ha öppna inkommande och utgående TCP-anslutningar för port 5022 och portintervall 11000-11999 för att underlätta kommunikationen mellan de två instanserna.
  • Hanterade instanser bör distribueras till parkopplade regioner för prestandaskäl. Hanterade instanser som finns i geo-parade regioner har nytta av en betydligt högre geo-replikeringshastighet jämfört med oparade regioner.
  • Båda instanserna måste använda samma uppdateringsprincip.

Skapa den sekundära instansen

När du skapar den sekundära instansen måste du använda ett virtuellt nätverk som har ett IP-adressutrymme som inte överlappar IP-adressutrymmet för den primära instansen. När du konfigurerar den nya sekundära instansen måste du dessutom ange zon-ID för den primära instansen.

Du kan konfigurera det sekundära virtuella nätverket och skapa den sekundära instansen med hjälp av Azure-portalen och PowerShell.

Skapa virtuella nätverk

Följ dessa steg för att skapa ett virtuellt nätverk för den sekundära instansen i Azure-portalen:

  1. Kontrollera adressutrymmet för den primära instansen. Gå till den virtuella nätverksresursen för den primära instansen i Azure-portalen och under Inställningar väljer du Adressutrymme. Kontrollera intervallet under Adressintervall:

    Skärmbild av adressutrymmet för det primära virtuella nätverket i Azure-portalen.

  2. Skapa ett nytt virtuellt nätverk som du planerar att använda för den sekundära instansen genom att gå till sidan Skapa virtuellt nätverk .

  3. På fliken Grundinställningar på sidan Skapa virtuellt nätverk :

    1. Välj den resursgrupp som du tänker använda för den sekundära instansen. Skapa en ny om den inte finns ännu.
    2. Ange ett namn för ditt virtuella nätverk, till exempel vnet-sql-mi-secondary.
    3. Välj en region som är kopplad till den region där den primära instansen finns.

  4. På fliken IP-adresser på sidan Skapa virtuellt nätverk :

    1. Använd Ta bort adressutrymme för att ta bort det befintliga IPv4-adressutrymmet.
    2. När adressutrymmet har tagits bort väljer du Lägg till IPv4-adressutrymme för att lägga till ett nytt utrymme och anger sedan ett IP-adressutrymme som skiljer sig från adressutrymmet som används av det virtuella nätverket för den primära instansen. Om din aktuella primära instans till exempel använder adressutrymmet 10.0.0.16 anger 10.1.0.0/16 du adressutrymmet för det virtuella nätverk som du tänker använda för den sekundära instansen.
    3. Använd + Lägg till ett undernät för att lägga till ett standardundernät med standardvärden.
    4. Använd + Lägg till ett undernät för att lägga till ett tomt undernät med namnet ManagedInstance som ska dedikeras till den sekundära instansen, med ett adressintervall som skiljer sig från standardundernätet. Om din primära instans till exempel använder ett adressintervall på 10.0.0.0–10.0.255.255, anger du ett undernätsintervall 10.1.1.0 - 10.1.1.255 för den sekundära instansens undernät.

    Skärmbild av adressutrymmet för ett nytt virtuellt nätverk i Azure-portalen.

  5. Använd Granska + Skapa för att granska inställningarna och använd sedan Skapa för att skapa ditt nya virtuella nätverk.

Skapa sekundär instans

När det virtuella nätverket är klart följer du de här stegen för att skapa din sekundära instans i Azure-portalen:

  1. Gå till Skapa Azure SQL Managed Instance i Azure-portalen.

  2. På fliken Grundinställningar på sidan Skapa Azure SQL Managed Instance :

    1. Välj en region för den sekundära instansen som är kopplad till den primära instansen.
    2. Välj en tjänstnivå som matchar tjänstnivån för den primära instansen.

  3. På fliken Nätverk på sidan Skapa Azure SQL Managed Instance använder du listrutan under Virtuellt nätverk/undernät för att välja det virtuella nätverket och undernätet som du skapade tidigare:

    Skärmbild som markerar det nätverk som du skapade för att använda med den sekundära instansen i Azure-portalen.

  4. På fliken Ytterligare inställningar på sidan Skapa Azure SQL Managed Instance väljer du Ja för att använda som sekundär redundans och väljer sedan lämplig primär instans i listrutan.

    Skärmbild av Azure-portalen som anger den primära hanterade instansen som sekundär redundans på sidan ytterligare inställningar.

  5. Konfigurera resten av instansen enligt dina affärsbehov och skapa den sedan med hjälp av Granska + skapa.

Upprätta anslutning mellan instanserna

För oavbrutet trafikflöde för geo-replikering måste du upprätta en anslutning mellan de virtuella nätverksundernät som är värdar för de primära och sekundära instanserna. Det finns flera sätt att ansluta hanterade instanser i olika Azure-regioner, inklusive:

Global peering för virtuella nätverkrekommenderas som det mest högpresterande och robusta sättet att upprätta anslutning mellan instanser i en redundansgrupp. Global peering för virtuella nätverk ger en privat anslutning med låg svarstid och hög bandbredd mellan peer-kopplade virtuella nätverk med hjälp av Microsofts staminfrastruktur. Vid kommunikation mellan peerkopplade virtuella nätverk krävs inget offentligt Internet, inga gatewayer och ingen ytterligare kryptering.

Viktigt!

Alternativa sätt att ansluta instanser som omfattar ytterligare nätverksenheter kan komplicera felsökningen av problem med anslutning eller replikeringshastighet, eventuellt kräva aktiv inblandning av nätverksadministratörer och potentiellt avsevärt förlänga lösningstiden.

Om du använder en mekanism för att upprätta en anslutning mellan andra instanser än den rekommenderade globala peeringen för virtuella nätverk kontrollerar du följande:

  • Nätverksenheter som brandväggar eller virtuella nätverksinstallationer (NVA) blockerar inte trafik på inkommande och utgående anslutningar för port 5022 (TCP) och portintervall 11000-11999.
  • Att routningen är korrekt konfigurerad och att inte asymmetrisk routning används.
  • Om du distribuerar redundansgrupper i en nav-och-eker-nätverkstopologi mellan regioner, för att undvika problem med anslutning och replikeringshastighet, bör replikeringstrafiken gå direkt mellan de två hanterade instansundernäten i stället för att dirigeras via hubbnätverken.

Den här artikeln beskriver hur du konfigurerar global peering för virtuella nätverk mellan nätverken för de två instanserna med hjälp av Azure-portalen och PowerShell.

  1. I Azure-portalen går du till resursen Virtuellt nätverk för din primära hanterade instans.

  2. Välj Peerings under Inställningar för att öppna sidan Peerings och använd sedan + Lägg till i kommandofältet för att öppna sidan Lägg till peering .

    Skärmbild av peerings-sidan för det virtuella nätverket A i Azure-portalen.

  3. På sidan Lägg till peering anger eller väljer du värden för följande inställningar:

    Inställningar Beskrivning
    Sammanfattning av fjärrvirtuellt nätverk
    Namn på peeringlänk Namnet på peering måste vara unikt i det virtuella nätverket. Den här artikeln använder Fog-peering.
    Distributionsmodell för virtuellt nätverk Välj Resurshanterare.
    Jag känner till mitt resurs-ID Du kan lämna den här rutan avmarkerad om du inte känner till resurs-ID:t.
    Prenumeration Välj prenumerationen i listrutan.
    Virtuellt nätverk Välj det virtuella nätverket för den sekundära instansen i listrutan.
    Inställningar för fjärrvirtuell nätverkspeering
    Tillåt "sekundärt virtuellt nätverk" att komma åt "primärt virtuellt nätverk" Markera kryssrutan för att tillåta kommunikation mellan de två nätverken. Genom att aktivera kommunikation mellan virtuella nätverk kan resurser som är anslutna till något av de virtuella nätverken kommunicera med varandra med samma bandbredd och svarstid som om de var anslutna till samma virtuella nätverk. All kommunikation mellan resurser i de två virtuella nätverken sker via det privata Azure-nätverket.
    Tillåt att "sekundärt virtuellt nätverk" tar emot vidarebefordrad trafik från "primärt virtuellt nätverk" Du kan antingen markera eller avmarkera den här rutan, vilket antingen fungerar för den här guiden. Mer information finns i Skapa en peering.
    Tillåt gateway- eller routningsserver i "sekundärt virtuellt nätverk" att vidarebefordra trafik till "primärt virtuellt nätverk" Du kan antingen markera eller avmarkera den här rutan, vilket antingen fungerar för den här guiden. Mer information finns i Skapa en peering.
    Aktivera "sekundärt virtuellt nätverk" för att använda fjärrgatewayen eller routningsservern för det primära virtuella nätverket Lämna den här rutan avmarkerad. För mer information om de övriga tillgängliga alternativen, se Skapa en peering.
    Sammanfattning av lokalt virtuellt nätverk
    Namn på peeringlänk Namnet på samma peering som används för det virtuella fjärrnätverket. Den här artikeln använder Fog-peering.
    Tillåt "primärt virtuellt nätverk" att komma åt "sekundärt virtuellt nätverk" Markera kryssrutan för att tillåta kommunikation mellan de två nätverken. Genom att aktivera kommunikation mellan virtuella nätverk kan resurser som är anslutna till något av de virtuella nätverken kommunicera med varandra med samma bandbredd och svarstid som om de var anslutna till samma virtuella nätverk. All kommunikation mellan resurser i de två virtuella nätverken sker via det privata Azure-nätverket.
    Tillåt att "primärt virtuellt nätverk" tar emot vidarebefordrad trafik från "sekundärt virtuellt nätverk" Du kan antingen markera eller avmarkera den här rutan, vilket antingen fungerar för den här guiden. Mer information finns i Skapa en peering.
    Tillåt gateway- eller routningsserver i "primärt virtuellt nätverk" att vidarebefordra trafik till "sekundärt virtuellt nätverk" Du kan antingen markera eller avmarkera den här rutan, vilket antingen fungerar för den här guiden. Mer information finns i Skapa en peering.
    Aktivera "primärt virtuellt nätverk" för att använda "sekundärt virtuellt nätverks fjärrgateway eller routningsserver Lämna den här rutan avmarkerad. För mer information om de övriga tillgängliga alternativen, se Skapa en peering.

  4. Använd Lägg till för att konfigurera peering med det virtuella nätverk som du har valt och navigera automatiskt tillbaka till sidan Peerings , som visar att de två nätverken är anslutna:

    Skärmbild av peeringstatus för virtuellt nätverk på peeringssidan i Azure-portalen.

Konfigurera portar och NSG-regler

Oavsett den valda anslutningsmekanismen mellan de två instanserna måste dina nätverk uppfylla följande krav för flödet av geo-replikeringstrafik:

  • Routningstabellen och nätverkssäkerhetsgrupperna som tilldelats undernäten för den hanterade instansen delas inte mellan de två peerkopplade virtuella nätverken.
  • NSG-reglerna (Network Security Group) på båda undernäten som är värdar för varje instans tillåter både inkommande och utgående trafik till den andra instansen på port 5022 och portintervallet 11000-11999.

Du kan konfigurera portkommunikation och NSG-regler med hjälp av Azure-portalen och PowerShell.

Så här öppnar du NSG-portar (Network Security Group) i Azure-portalen:

  1. Gå till resursen Nätverkssäkerhetsgrupp för den primära instansen.

  2. Välj Inkommande säkerhetsregel under Inställningar. Kontrollera om du redan har regler som tillåter trafik för port 5022 och intervallet 11000-11999. Om du gör det och källan uppfyller dina affärsbehov hoppar du över det här steget. Om reglerna inte finns eller om du vill använda en annan källa (till exempel den säkrare IP-adressen) tar du bort den befintliga regeln och väljer sedan + Lägg till i kommandofältet för att öppna fönstret Lägg till inkommande säkerhetsregel :

    Skärmbild av att lägga till inkommande säkerhetsregler för nätverkssäkerhetsgruppen i Azure-portalen.

  3. I fönstret Lägg till inkommande säkerhetsregel anger eller väljer du värden för följande inställningar:

    Inställningar Rekommenderat värde Beskrivning
    Källa IP-adresser eller servicetag Filtret för källan till kommunikationen. IP-adressen är den säkraste och rekommenderas för produktionsmiljöer. Servicetaggen är lämplig för icke-produktionsmiljöer.
    Servicetagg för källa Om du har valt Tjänsttagg som källa anger VirtualNetwork du som källtagg. Standardtaggar är fördefinierade identifierare som representerar en kategori med IP-adresser. VirtualNetwork-taggen anger alla virtuella och lokala nätverksadressutrymmen.
    Källans IP-adress Om du har valt IP-adresser som källa anger du IP-adressen för den sekundära instansen. Ange ett adressintervall med CIDR-notation (t.ex. 192.168.99.0/24 eller 2001:1234::/64) eller en IP-adress (t.ex. 192.168.99.0 eller 2001:1234::). Du kan också ange en kommaavgränsad lista över IP-adresser eller adressintervall med IPv4 eller IPv6.
    Källportsintervall 5022 Detta anger på vilka portar trafik ska tillåtas enligt denna regel.
    Tjänster Skräddarsydd Tjänsten anger målprotokollet och portintervallet för den här regeln.
    Intervall för målportar 5022 Detta anger på vilka portar trafik ska tillåtas enligt denna regel. Den här porten ska matcha källportintervallet.
    Åtgärd Tillåt Tillåt kommunikation på den angivna porten.
    Protokoll TCP Avgör protokollet för portkommunikation.
    Prioritet 1200 Regler bearbetas i prioritetsordning. desto lägre tal, desto högre prioritet.
    Namn tillåt_geodr_inåtgående Namnet på regeln.
    Beskrivning Valfritt Du kan välja att ange en beskrivning eller lämna fältet tomt.

    Välj Lägg till för att spara inställningarna och lägg till den nya regeln.

  4. Upprepa de här stegen för att lägga till ytterligare en regel för inkommande säkerhet för portintervallet 11000-11999 med ett namn som allow_redirect_inbound och en prioritet som är något högre än 5022-regeln, till exempel 1100.

  5. Under Inställningar väljer du Utgående säkerhetsregler. Kontrollera om du redan har regler som tillåter trafik för port 5022 och intervallet 11000-11999. Om du gör det och källan uppfyller dina affärsbehov hoppar du över det här steget. Om reglerna inte finns eller om du vill använda en annan källa (till exempel den säkrare IP-adressen) tar du bort den befintliga regeln och väljer sedan + Lägg till i kommandofältet för att öppna fönstret Lägg till utgående säkerhetsregel .

  6. I fönstret Lägg till utgående säkerhetsregel använder du samma konfiguration för port 5022 och intervallet 11000-11999 som du gjorde för de inkommande portarna.

  7. Gå till nätverkssäkerhetsgruppen för den sekundära instansen och upprepa dessa steg så att båda nätverkssäkerhetsgrupperna har följande regler:

    • Tillåt inkommande trafik på port 5022
    • Tillåt inkommande trafik för portar i området 11000-11999
    • Tillåt utgående trafik på port 5022
    • Tillåt utgående trafik på portspann 11000-11999

Skapa redundansgruppen

Skapa redundansgruppen för dina hanterade instanser med hjälp av Azure-portalen eller PowerShell.

Skapa redundansgruppen för dina SQL Managed Instances med hjälp av Azure-portalen.

  1. Välj Azure SQL på den vänstra menyn i Azure-portalen. Om Azure SQL inte finns med i listan väljer du Alla tjänster och skriver sedan Azure SQL i sökrutan. (Valfritt) Välj stjärnan bredvid Azure SQL för att lägga till den som ett favoritobjekt i det vänstra navigeringsfältet.

  2. Välj den primära hanterade instans som du vill lägga till i redundansgruppen.

  3. Under Datahantering väljer du Redundansgrupper och använder sedan Lägg till grupp för att öppna sidan Redundansgrupp för instans :

    Skärmbild av att lägga till en sida för redundansgrupper i Azure-portalen.

  4. På sidan Redundansgrupp för instans :

    1. Den primära hanterade instansen är förvald.
    2. Under Namn på redundansgrupp anger du ett namn för redundansgruppen.
    3. Under Sekundär hanterad instans väljer du den hanterade instans som du vill använda som sekundär i redundansgruppen.
    4. Välj en redundansprincip för läsning/skrivning i listrutan. Manuell rekommenderas för att ge dig kontroll över avbrottshanteringen.
    5. Lämna Aktivera redundansrättigheter till Av, såvida du inte tänker använda den här repliken endast för haveriberedskap.
    6. Använd Skapa för att spara inställningarna och skapa redundansgruppen.

    Skärmbild för att skapa redundansgrupp i Azure-portalen.

  5. När distributionen av failovergrupper har startat tas du tillbaka till sidan Failover-grupper. Sidan uppdateras för att visa den nya redundansgruppen när distributionen har slutförts.

Testa övergång till reservsystem

Testa redundans för redundansgruppen med hjälp av Azure-portalen eller PowerShell.

Testa redundans för redundansgruppen med hjälp av Azure-portalen.

  1. Gå till antingen den primära eller sekundära hanterade instansen i Azure-portalen.

  2. Under Datahantering väljer du Redundansgrupper.

  3. I fönstret Redundansgrupper noterar du vilken instans som är den primära instansen och vilken instans som är den sekundära instansen.

  4. I fönstret Redundansgrupper väljer du Redundans i kommandofältet. Välj Ja på varningen om att TDS-sessioner kopplas från och notera licensieringskonsekvenserna.

    Skärmbild för att växla över failovergruppen i Azure-portalen.

  5. På fönstret Redundansgrupper, när övergången har slutförts, växlar instanserna roller så att den tidigare sekundära blir den nya primära och den tidigare primära blir den nya sekundära.

    Viktigt!

    Om rollerna inte växlade kontrollerar du anslutningen mellan instanserna och relaterade NSG- och brandväggsregler. Fortsätt med nästa steg först efter att rollerna har växlats.

  6. (Valfritt) I fönstret Redundansgrupper använder du Redundans för att växla tillbaka rollerna så att den ursprungliga primära blir primär igen.

Spåra redundans i aktivitetsloggen

Du kan använda aktivitetsloggen i Azure-portalen för att spåra status för redundansåtgärden. Gör detta genom att följa dessa steg:

  1. Gå till din SQL-hanterade instans i Azure-portalen.

  2. Välj Aktivitetslogg för att öppna fönstret Aktivitetslogg .

  3. Rensa eventuella filter för Resurs.

  4. Sök efter åtgärder med namnet Failover Azure SQL Database failover group:

    Skärmbild av aktivitetsloggen för din SQL-hanterade instans i Azure-portalen med en redundansåtgärd markerad.

Ändra befintlig redundansgrupp

Du kan ändra en befintlig redundansgrupp, till exempel för att ändra redundansprincipen, med hjälp av Azure-portalen, PowerShell, Azure CLI och REST-API:erna.

Följ dessa steg om du vill ändra en befintlig redundansgrupp med hjälp av Azure-portalen:

  1. Gå till din SQL-hanterade instans i Azure-portalen.

  2. Under Datahantering väljer du Redundansgrupper för att öppna fönstret Redundansgrupper .

  3. I fönstret Redundansgrupper väljer du Redigera konfigurationer från kommandofältet för att öppna fönstret Redigera redundansgrupp :

    Skärmbild av panelen för failovergrupp i Azure-portalen med Redigera konfigurationer markerat.

Leta upp lyssnarens slutpunkt

När redundansgruppen har konfigurerats uppdaterar du anslutningssträngen för ditt program så att den pekar på läs-/skrivlyssningsslutpunkten så att programmet fortsätter att ansluta till den instans som är primär efter redundansväxlingen. Genom att använda lyssnarens slutpunkt behöver du inte uppdatera anslutningssträngen manuellt varje gång din failover-grupp växlar över eftersom trafiken alltid dirigeras till den aktuella primära servern. Du kan också rikta skrivskyddade arbetsbelastningar till slutpunkten för skrivskyddade lyssnaren.

Viktigt!

När du ansluter till en instans i en redundansgrupp med hjälp av den instansspecifika anslutningssträngen är det starkt avrått. Använd lyssnarens slutpunkter i stället.

Om du vill hitta lyssnarens slutpunkt i Azure-portalen går du till din SQL-hanterade instans och under Datahantering väljer du Redundansgrupper.

Bläddra nedåt för att hitta lyssnarens endpunkter.

  • Läsa/skriv lyssnarens slutpunkt i form av fog-name.dns-zone.database.windows.net dirigerar trafik till den primära instansen.
  • Slutpunkten skrivskyddad lyssnare dirigerar trafik till den sekundära instansen i form av fog-name.secondary.dns-zone.database.windows.net.

Skärmbild där du hittar anslutningssträngen för redundansgrupper i Azure-portalen.

Skapa redundansgrupp mellan instanser i olika prenumerationer

Du kan skapa en redundansgrupp mellan SQL Managed Instances i två olika prenumerationer, så länge prenumerationer är associerade med samma Microsoft Entra-klientorganisation.

  • När du använder PowerShell API kan du göra det genom att ange parametern PartnerSubscriptionId för den sekundära SQL Managed Instance.
  • När du använder REST API kan varje instans-ID som ingår i parametern properties.managedInstancePairs ha ett eget prenumerations-ID.
  • Azure-portalen har inte stöd för att skapa redundansgrupper i olika prenumerationer.

Viktigt!

Att skapa en redundansgrupp mellan två instanser i olika resursgrupper eller prenumerationer stöds bara med Azure PowerShell eller REST-API:et, och inte Azure-portalen eller Azure CLI.

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. Ett anrop till sp_wait_for_database_copy_sync blockerar den anropande tråden tills den senaste committerade transaktionen har överförts och härdats i den sekundära databasens transaktionslogg. Det väntar dock inte på att de överförda transaktionerna ska spelas upp igen (upprepas) på den sekundära servern. 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-failover ändrar replikeringen automatiskt och tillfälligt till synkron replikering och utför en redundansväxling. Replikeringen återgår sedan till asynkront läge när geo-failover är avslutad.

Anmärkning

sp_wait_for_database_copy_sync förhindrar dataförlust efter geo-felövergång 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.

Ändra den sekundära regionen

Anta att instans A är den primära instansen, instans B är den befintliga sekundära instansen och instans C är den nya sekundära instansen i den tredje regionen. Gör övergången genom att följa dessa steg:

  1. Skapa instans C med samma storlek som A och i samma DNS-zon.
  2. Ta bort failovergruppen mellan instanserna A och B. Vid det här tillfället börjar försök att logga in misslyckas eftersom SQL-aliaserna för failovergruppens lyssnare har tagits bort och gatewayen inte känner igen failovergruppens namn. De sekundära databaserna kopplas från de primära och blir skriv- och läsbara databaser.
  3. Skapa en redundansgrupp med samma namn mellan instans A och C. Följ anvisningarna i guiden Konfigurera redundansgrupp. Det här är en datastorleksåtgärd som slutförs när alla databaser från instans A är seedade och synkroniserade.
  4. Ta bort instans B om det inte behövs för att undvika onödiga avgifter.

Anmärkning

Efter steg 2 och tills steg 3 har slutförts förblir databaserna i instans A oskyddade från ett oåterkalleligt fel i instans A.

Ändra den primära regionen

Anta att instans A är den primära instansen, instans B är den befintliga sekundära instansen och instans C är den nya primära instansen i den tredje regionen. Gör övergången genom att följa dessa steg:

  1. Skapa instans C med samma storlek som B och i samma DNS-zon.
  2. Initiera en manuell redundansväxling från instans B för att göra den till den nya primära. Instans A blir automatiskt den nya sekundära instansen.
  3. Ta bort redundansgruppen mellan instanserna A och B. Nu börjar inloggningsförsök med slutpunkter för redundansgrupper att misslyckas. De sekundära databaserna på A är frånkopplade från de primära databaserna och blir databaser som kan läsas och skrivas.
  4. Skapa en redundansgrupp med samma namn mellan instans B och C. Det här är en datastorleksåtgärd som slutförs när alla databaser från instans B är seedade och synkroniserade med instans C. Nu slutar inloggningsförsöken att misslyckas.
  5. Manuellt utför en failover för att växla C-instansen till den primära rollen. Instans B blir automatiskt den nya sekundära instansen.
  6. Ta bort instans A om det inte behövs för att undvika onödiga avgifter.

Försiktighet

När steg 3 och tills steg 4 har slutförts förblir databaserna i instans A oskyddade från ett oåterkalleligt fel i instans A.

Viktigt!

När redundansgruppen tas bort tas även DNS-posterna för lyssnarens slutpunkter bort. Då finns det en sannolikhet som inte är noll för att någon annan ska skapa en redundansgrupp med samma namn. Eftersom namn på redundanskluster måste vara globalt unika hindrar detta dig från att använda samma namn igen. För att minimera den här risken, använd inte generiska namn för failover-grupper.

Ändra uppdateringsprincip

Instanser i en redundansgrupp måste ha matchande uppdateringsprinciper. Om du vill ändra uppdateringsprincipen till en högre version på instanser som ingår i en redundansgrupp aktiverar du först uppdateringsprincipen på den sekundära instansen, väntar tills ändringen börjar gälla och uppdaterar sedan principen för den primära instansen.

När du ändrar uppdateringsprincipen för den primära instansen i redundansgruppen leder det till att instansen redundansväxlar till en annan lokal nod (liknar hanteringsåtgärder på instanser som inte ingår i en redundansgrupp), men det gör inte att redundansgruppen redundansväxlar, vilket behåller den primära instansen i den primära rollen.

Försiktighet

När den uppdaterade principen har ändrats till högre SQL Server-version, inklusive Always-up-to-date, är det inte längre möjligt att ändra tillbaka den till den lägre versionsuppdateringsprincipen.

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

Systemdatabaser inte replikeras till sekundärinstansen i en failover-grupp. Om du vill aktivera scenarier som är beroende av objekt från systemdatabaserna måste du skapa samma objekt på 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 kvarhållningsprincipinstanser

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.

Skalningsinstanser

Konfigurationen av din primära och sekundära instans bör vara densamma. Detta omfattar beräkningsstorlek, lagringsstorlek och tjänstnivå. Om du behöver ändra konfigurationen för redundansgruppen kan du göra det genom att skala varje instans till samma konfiguration i enlighet med detta.

Tänk på följande för att undvika problem från en lägre tjänstnivå eller underbearbetad geo-sekundär som överbelastas eller måste återställas under en uppgraderings- eller nedgraderingsprocess:

  • Du kan skala upp eller 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å skalar du först upp den geo-sekundära och skalar sedan 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.
  • Samma sekvens framtvingas när du skalar en instans till en annan tjänstnivå eller när du ändrar minnesallokeringen för din nästa generations generell användning-instans .
  • Åtgärdssekvensen tillämpas också när du skalar lagring, samt ändrar antalet virtuella kärnor.

Viktigt!

  • För instanser inom en failover-grupp, stöds det inte att ändra tjänstenivån till eller från Nästa generations General Purpose-nivå. Du måste först ta bort failover-gruppen innan du ändrar någon av replikerna och sedan återskapa failover-gruppen när ändringen träder i kraft.

Behörigheter

Behörigheter för en redundansgrupp hanteras via rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Rollen SQL Managed Instance-deltagare, som är begränsad till resursgrupperna för den primära och den sekundära hanterade instansen, räcker för att utföra alla hanteringsåtgärder i redundansgrupper.

Följande tabell innehåller detaljerad vy över minimala behörigheter som krävs och deras respektive minsta nödvändiga omfångsnivåer för hanteringsåtgärder i redundansgrupper:

Förvaltningsoperation Tillåtelse Omfattning
Skapa/uppdatera redundansgrupp Microsoft.Sql/locations/instanceFailoverGroups/write Resursgrupper för primär och sekundär hanterad instans
Skapa/uppdatera redundansgrupp Microsoft.Sql/managedInstances/write Primär och sekundär hanterad instans
Redundansväxlingsgrupp Microsoft.Sql/locations/instanceFailoverGroups/failover/action Resursgrupper för primär och sekundär hanterad instans
Framtvinga redundansväxlingsgrupp Microsoft.Sql/locations/instanceFailoverGroups/forceFailoverAllowDataLoss/action Resursgrupper för primär och sekundär hanterad instans
Ta bort redundansgrupp Microsoft.Sql/locations/instanceFailoverGroups/delete Resursgrupper för primär och sekundär hanterad instans

Begränsningar

När du skapar en ny redundansgrupp bör du överväga följande begränsningar:

  • Redundansgrupper kan inte skapas mellan två instanser i samma Azure-region.
  • En instans kan bara delta i en redundansgrupp när som helst.
  • Det går inte att skapa en redundansgrupp mellan två instanser som tillhör olika Azure-klientorganisationer.
  • Att skapa en redundansgrupp mellan två instanser i olika resursgrupper eller prenumerationer stöds bara med Azure PowerShell eller REST-API:et, och inte Azure-portalen eller Azure CLI. När redundansgruppen har skapats visas den i Azure-portalen och alla åtgärder stöds i Azure-portalen eller med Azure CLI.
  • Om den inledande seedningen av alla databaser inte slutförs inom 7 dagar misslyckas redundansgruppen och alla replikerade databaser tas bort från den sekundära instansen.
  • Det går för närvarande inte att skapa en redundansgrupp med en instans som konfigurerats med en hanterad instanslänk .
  • Redundansgrupper kan inte skapas mellan instanser om någon av dem finns i en instanspool.
  • Databaser som migreras till Azure SQL Managed Instance med hjälp av Log Replay Service (LRS) kan inte läggas till i en redundansgrupp förrän snabbsteget har körts.

Tänk på följande begränsningar när du använder redundansgrupper:

  • Det går inte att byta namn på redundansgrupper. Du måste ta bort gruppen och återskapa den med ett annat namn.
  • En redundansgrupp innehåller exakt två hanterade instanser. Det går inte att lägga till ytterligare instanser i failover-gruppen.
  • Fullständiga säkerhetskopior görs automatiskt:
    • innan den inledande såddprocessen påbörjas och kan avsevärt fördröja starten av processen.
    • efter redundansväxlingen och kan fördröja eller förhindra en efterföljande redundansväxling.
  • Ändring av databasen (döp om databas) stöds inte för databaser i failover-gruppen. Du måste tillfälligt ta bort redundansgruppen för att kunna byta namn på en databas.
  • Systemdatabaser replikeras inte till den sekundära instansen i en redundansgrupp. Därför kräver scenarier som är beroende av objekt från systemdatabaser som serverinloggningar och agentjobb att objekt skapas manuellt på de sekundära instanserna och även synkroniseras manuellt efter ändringar som gjorts på den primära instansen. Det enda undantaget är Tjänstens huvudnyckel (SMK) för SQL Managed Instance som replikeras automatiskt till sekundär instans när redundansgruppen skapas. Eventuella efterföljande ändringar av SMK på den primära instansen replikeras dock inte till den sekundära instansen. Mer information finns i Aktivera scenarier som är beroende av objekt från systemdatabaserna.
  • För instanser i en failover-grupp stöds det inte att ändra tjänstnivån till eller från Next-gen General Purpose-nivån. Du måste först ta bort failover-gruppen innan du ändrar någon av replikerna och sedan återskapa failover-gruppen när ändringen träder i kraft.
  • SQL-hanterade instanser i en redundansgrupp måste ha samma uppdateringsprincip, även om det är möjligt att ändra uppdateringsprincipen för instanser i en redundansgrupp.

Hantera redundansgrupper programmatiskt

Redundansgrupper kan också hanteras programmatiskt med hjälp av Azure PowerShell, Azure CLI och REST API. I följande tabeller beskrivs vilken uppsättning kommandon som är tillgängliga. Redundansgrupper innehåller en uppsättning Azure Resource Manager-API:er för hantering, inklusive Azure SQL Database REST API och Azure PowerShell-cmdletar. Dessa API:er kräver användning av resursgrupper och stöder rollbaserad åtkomstkontroll i Azure (Azure RBAC). Mer information om hur du implementerar åtkomstroller finns i Rollbaserad åtkomstkontroll i Azure (Azure RBAC).

Cmdlet (ett PowerShell-kommando) Beskrivning
New-AzSqlDatabaseInstanceFailoverGroup Det här kommandot skapar en redundansgrupp och registrerar den på både primära och sekundära instanser
Set-AzSqlDatabaseInstanceFailoverGroup Ändrar konfigurationen av en redundansgrupp
Get-AzSqlDatabaseInstanceFailoverGroup Hämtar konfigurationen för en redundansgrupp
Switch-AzSqlDatabaseInstanceFailoverGroup Initierar överflyttning av en failovergrupp till den sekundära instansen
Remove-AzSqlDatabaseInstanceFailoverGroup Tar bort en redundansgrupp

Relaterat innehåll