Vad är en innesluten tillgänglighetsgrupp?

gäller för: SQL Server 2022 (16.x)

En innesluten tillgänglighetsgrupp är en AlwaysOn-tillgänglighetsgrupp (AG) som stöder:

• hantera metadataobjekt (användare, inloggningar, behörigheter, SQL Agent-jobb och så vidare) på ag-nivå utöver instansnivån.

• specialiserade inneslutna systemdatabaser inom AG.

Den här artikeln beskriver likheterna, skillnaderna och funktionerna i inneslutna AG:er.

Överblick

AG:er består vanligtvis av en eller flera användardatabaser som är avsedda att fungera som en samordnad grupp och som replikeras på ett antal noder i ett kluster. När det uppstår ett fel i noden, eller i hälsotillståndet för SQL Server på noden som är värd för den primära kopian, flyttas gruppen med databaser som en enhet till en annan repliknod i tillgänglighetsgruppen. Alla användardatabaser hålls synkroniserade mellan alla repliker av tillgänglighetsgruppen (AG), antingen i synkront eller asynkront läge.

Detta fungerar bra för program som bara interagerar med den uppsättningen användardatabaser, men det finns utmaningar när program också förlitar sig på objekt som användare, inloggningar, behörigheter, agentjobb osv., som lagras i en av systemdatabaserna (master eller msdb). För att applikationerna ska fungera smidigt och förutsägbart måste administratören manuellt se till att alla ändringar av dessa objekt dupliceras över alla replikinstanser i AG:n. Om en ny instans tas med i tillgänglighetsgruppen kan databaserna automatiskt eller manuellt seedas i en enkel process, men sedan måste alla systemdatabasanpassningar konfigureras om på den nya instansen för att matcha de andra replikerna.

Inneslutna AG:er utökar begreppet databasgrupp som replikeras till att omfatta relevanta delar av master och msdb databaser. Tänk på det som körningskontexten för applikationer som använder den inneslutna AG. Tanken är att den inneslutna AG-miljön innehåller inställningar som skulle påverka applikationen som är beroende av dem. Därför gäller den inneslutna AG-miljön alla databaser som programmet interagerar med, den autentisering som används (inloggningar, användare, behörigheter), alla schemalagda uppgifter som förväntas köras och andra konfigurationsinställningar som påverkar programmet.

Detta skiljer sig från inneslutna databaser, som använder en annan mekanism för användarkontona och lagrar användarinformationen i själva databasen. Inneslutna databaser replikerar endast inloggningar och användare, och omfattningen för den replikerade inloggningen eller användaren är begränsad till den enskilda databasen (och dess repliker).

I en innesluten tillgänglighetsgrupp kan du däremot skapa användare, inloggningar, behörigheter och så vidare, på tillgänglighetsgruppens nivå, och de automatiskt konsekventa mellan repliker i tillgänglighetsgruppen, samt konsekventa mellan databaser i den tillgängliga tillgänglighetsgruppen. Detta sparar administratören från att behöva göra dessa ändringar manuellt.

Skillnader

Det finns några praktiska skillnader att tänka på när man arbetar med inneslutna tillgänglighetsgrupper (AG:er), såsom skapandet av inneslutna systemdatabaser och att tvinga fram anslutningen på nivån för den inneslutna tillgänglighetsgruppen i stället för på instansnivå.

Inneslutna systemdatabaser

Varje tillgänglighetsgrupp har sina egna master och msdb systemdatabaser, namngivna efter tillgänglighetsgruppens namn. I den i sammanhanget angivna AG MyContainedAG, har du till exempel databaser som heter MyContainedAG_master och MyContainedAG_msdb. Dessa systemdatabaser skickas automatiskt till nya repliker och uppdateringar replikeras till dessa databaser precis som andra databaser i en tillgänglighetsgrupp. Det innebär att när du lägger till ett objekt, till exempel ett inloggnings- eller agentjobb när du är ansluten till den inneslutna tillgänglighetsgruppen, när den inneslutna tillgänglighetsgruppen redundansväxlar till en annan instans, ansluter till den inneslutna tillgänglighetsgruppen, ser du fortfarande agentjobben och kan autentisera med inloggningen som skapades i den inneslutna tillgänglighetsgruppen.

Systemdatabaserna i en nyligen skapad inneslutna AG är inte kopior från den instans där kommandot CREATE AVAILABILITY GROUP körs. De är initialt tomma mallar utan data. Omedelbart efter skapandet kopieras administratörskontona på den instans som skapar den inneslutna tillgänglighetsgruppen till den inneslutna tillgänglighetsgruppen master. På så sätt kan administratören logga in på den inneslutna tillgänglighetsgruppen och slutföra resten av konfigurationen.

Om du skapar lokala användare eller konfigurationer i din instans visas de inte automatiskt när du skapar dina inneslutna systemdatabaser och de visas inte när du ansluter till den inneslutna tillgänglighetsgruppen. När användardatabasen har anslutits till en avgränsad tillgänglighetsgrupp blir den omedelbart inte tillgänglig för dessa användare. Du måste manuellt återskapa dem i de avgränsade systemdatabaserna inom kontexten för den Inneslutna Tillgänglighetsgruppen, genom att ansluta direkt till databasen eller med hjälp av lyssnarens slutpunkt. Undantaget är att alla inloggningar i sysadmin-rollen i den överordnade instansen kopieras till den nya tillgänglighetsgruppsspecifika master-databasen.

Återställa en innesluten systemdatabas

Du kan återställa en innesluten systemdatabas på något av två olika sätt.

• Återställa en innesluten databas med hjälp av en sekundär replik:

  1. Återställ den inneslutna master- och msdb-databasen till en serverinstans som är värd för den sekundära repliken med hjälp av RESTORE WITH NORECOVERY för varje återställningsåtgärd. Mer information finns i Förbereda en sekundär databas för en AlwaysOn-tillgänglighetsgrupp.

  2. Koppla varje innesluten databas till tillgänglighetsgruppen. Mer information finns i Ansluta en sekundär databas till en AlwaysOn-tillgänglighetsgrupp.

• Återställ en innesluten databas genom att ta bort den inneslutna Availability Group (AG):

  1. Släpp den inneslutna AG:n.

  2. Återställ den inneslutna master- och msdb-databasen i var och en av de instanser som deltar i den inneslutna tillgänglighetsgruppen.

  3. Återskapa den inneslutna tillgänglighetsgruppen med ursprungliga noder och deras namn, med WITH (CONTAINED, REUSE_SYSTEM_DATABASES)-syntax.

Anslut (avgränsad miljö)

Det är viktigt att skilja skillnaden mellan att ansluta till instansen och ansluta till den inneslutna tillgänglighetsgruppen. Det enda sättet att komma åt miljön för den inneslutna tillgänglighetsgruppen är att ansluta till den inneslutna tillgänglighetsgruppens lyssnare eller att ansluta till en databas som finns i den inneslutna tillgänglighetsgruppen.

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

Där MyContainedDatabase är en databas inom den inneslutna tillgänglighetsgruppen som du vill interagera med.

Det innebär att du måste skapa en lyssnare för den inneslutna tillgänglighetsgruppen för att effektivt använda en innesluten tillgänglighetsgrupp. Om du ansluter till en av de instanserna som är värd för den inneslutna tillgänglighetsgruppen i stället för att direkt till den inneslutna tillgänglighetsgruppen via lyssnarenär du i miljön för instansen och inte den inneslutna tillgänglighetsgruppen.

Om tillgänglighetsgruppen till exempel MyContainedAG finns på servern SERVER\MSSQLSERVERoch i stället för att ansluta till lyssnaren MyContainedAG_Listeneransluter du till instansen med SERVER\MSSQLSERVER, är du i instansens miljö och inte i miljön för MyContainedAG. Det innebär att du omfattas av innehållet (användare, behörigheter, jobb osv.) som finns i systemdatabaserna i instansen. För att komma åt innehållet som finns i de inneslutna systemdatabaserna i den inneslutna tillgänglighetsgruppen ansluter du till den inneslutna tillgänglighetsgruppens lyssnare (MyContainedAG_Listener, till exempel) i stället. När du ansluter till instansen via lyssnaren för den begränsade tillgänglighetsgruppen och interagerar med master, blir du faktiskt omdirigerad till den begränsade master-databasen (till exempel MyContainedAG_master).

Skrivskyddad routning och inneslutna tillgänglighetsgrupper

Om du konfigurerar skrivskyddad routning för att omdirigera anslutningar med läsintention till en sekundär replik (se Konfigurera skrivskyddad routning för en Always On-tillgänglighetsgrupp) och du vill ansluta med en inloggning som endast har skapats inom den inneslutna tillgänglighetsgruppen finns det några ytterligare överväganden:

• Du måste ange en databas som ingår i den bundna tillgänglighetsgruppen i anslutningssträngen
• Användaren som anges i anslutningssträngen måste ha behörighet att komma åt databaserna i den inneslutna tillgänglighetsgruppen.

Till exempel i följande anslutningssträng, där AdventureWorks är en databas i den inneslutna tillgänglighetsgruppen som har MyContainedListener, och där MyUser är en användare som definierats i den inneslutna tillgänglighetsgruppen och ingen av de deltagande instanserna:

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"

Den här anslutningssträngen gör att du ansluter till den läsbara sekundära som är en del av ReadOnly Routing-konfigurationen, och du skulle vara inom kontexten för den inneslutna tillgänglighetsgruppen.

Skillnader mellan att ansluta till instansen och ansluta till den inneslutna tillgänglighetsgruppen

• När de är anslutna till en innesluten tillgänglighetsgrupp ser användarna bara databaser i den inneslutna tillgänglighetsgruppen, plus tempdb.
• På instansnivå är de innehållna AG-namnen master och msdb, [contained AG]_masteroch [contained AG]_msdb. I det inneslutna AG är deras namn master och msdb.
• Databas-ID för den inneslutna AG:n master är 1 inifrån den inneslutna AG:n, men något annat när den är ansluten till instansen.
• Även om användarna inte ser databaser utanför den inneslutna tillgänglighetsgruppen i sys.databases när de är anslutna i en innesluten tillgänglighetsgruppsanslutning, kan de komma åt dessa databaser med tredelade namn eller via kommandot USE.
• Serverkonfiguration via sp_configure kan läsas från den inneslutna AG-anslutningen, men kan endast skrivas på instansnivå.
• Från inneslutna AG-anslutningar kan sysadmin utföra åtgärder på instansnivå, till exempel stänga av SQL Server.
• De flesta åtgärder på databasnivå, ändpunktsnivå eller tillgänglighetsgruppsnivå kan endast utföras från instansanslutningar, inte från kontrollerade tillgänglighetsgruppsanslutningar.

Interaktioner med andra funktioner

Det finns ytterligare saker att tänka på när du använder vissa funktioner med inneslutna AG:er, och det finns vissa funktioner som för närvarande inte stöds.

Stöds inte

För närvarande stöds inte följande SQL Server-funktioner i en innesluten tillgänglighetsgrupp:

• SQL Server-replikering av valfri typ (transaktionell, sammanslagning, ögonblicksbild och så vidare).
• Distribuerade tillgänglighetsgrupper.
• Loggleverans där måldatabasen finns i den avgränsade tillgänglighetsgruppen. Loggleverans med källdatabasen i den inneslutna tillgänglighetsgruppen stöds.

Ändra datainsamling

Ändringsdatainsamling (CDC) implementeras som SQL Agent-jobb, så SQL-agenten måste köras på alla instanser med repliker i den innehållna AG:n.

Om du vill använda Change Data Capture med en tillgänglighetsgrupp med inneslutet läge, anslut till lyssnaren för tillgänglighetsgruppen när du konfigurerar CDC så att CDC-metadata konfigureras med hjälp av de inneslutna systemdatabaserna.

Loggöverföring

Loggleverans kan konfigureras om källdatabasen finns i den inneslutna tillgänglighetsgruppen. Ett loggleveransmål stöds dock inte i en avgränsad tillgänglighetsgrupp. Dessutom finns det ett extra steg för att ändra loggleveransjobbet när CDC har konfigurerats.

Följ dessa steg för att konfigurera loggöverföring med en innesluten tillgänglighetsgrupp (AG):

1. Anslut till den begränsade AG-lyssnaren.
2. Konfigurera loggöverföring som du normalt skulle göra.
3. När loggleveransjobbet har konfigurerats ändrar du det för att ansluta till lyssnaren för den inneslutna tillgänglighetsgruppen (AG) innan du säkerhetskopierar.

Transparent datakryptering (TDE)

Om du vill använda transparent datakryptering (TDE) med databaser i en innesluten tillgänglighetsgrupp installerar du manuellt databashuvudnyckeln (DMK) till den inneslutna master databasen i den inneslutna tillgänglighetsgruppen.

Databaser som använder TDE förlitar sig på certifikat i master-databasen för att dekryptera databaskrypteringsnyckeln (DEK). Utan det certifikatet kan SQL Server inte dekryptera databaser som krypterats med TDE eller föra dem online. I en kontrollerad AG, kontrollerar SQL Server både master-databaserna för DMK, master-databasen för instansen och den inneslutna master-databasen inom den inneslutna AG:n för att dekryptera databasen. Om det inte kan hitta certifikatet på någon av platserna kan SQL Server inte ansluta databasen.

Om du vill överföra DMK:n från instansens master databas till den inneslutna master-databasen kan du läsa Flytta en TDE-skyddad databas till en annan SQL Server-, främst med fokus på de delar där DMK överförs från den gamla servern till den nya.

SSIS-paket och underhållsplaner &

Användning av SSIS-paket, inklusive underhållsplaner, stöds inte med inneslutna tillgänglighetsgrupper.

DDL-ändringar

De enda DDL-ändringarna finns i CREATE AVAILABILITY GROUP arbetsflödet. Det finns två nya WITH-satser:

<with_option_spec> ::=
CONTAINED |
REUSE_SYSTEM_DATABASES

INNEHÖLL

Detta anger att den ag som skapas ska vara en avgränsad ag.

REUSE_SYSTEM_DATABASES

Det här alternativet är endast giltigt för inneslutna tillgänglighetsgrupper och anger att den nyligen skapade tillgänglighetsgruppen ska återanvända befintliga inneslutna systemdatabaser för en tidigare innesluten tillgänglighetsgrupp med samma namn. Om du till exempel hade en tillgänglighetsgrupp med begränsat omfång med namnet MyContainedAGoch ville ta bort och återskapa den, kan du använda det här alternativet för att återanvända innehållet i de ursprungliga systemdatabaserna som var inneslutna.

DMV-ändringar

Det finns två tillägg till DMV:er relaterade till inneslutna AG:er:

• DMV-sys.dm_exec_sessions har en tillagd kolumn: contained_availability_group_id
• Katalogvyn sys.availability_groups har den tillagda kolumnen: is_contained

Relaterat innehåll

• SKAPA TILLGÄNGLIGHETSGRUPP (Transact-SQL)