Wat is een ingesloten beschikbaarheidsgroep?

van toepassing op: SQL Server 2022 (16.x)

Een ingesloten beschikbaarheidsgroep is een AlwaysOn-beschikbaarheidsgroep (AG) die ondersteuning biedt voor:

• het beheren van metagegevensobjecten (gebruikers, aanmeldingen, machtigingen, SQL Agent-taken, enzovoort) op AG-niveau naast het exemplaarniveau.

• gespecialiseerde ingesloten systeemdatabases binnen de AG.

In dit artikel worden de overeenkomsten, verschillen en functionaliteiten van ingesloten AG's beschreven.

Overzicht

AG's bestaan over het algemeen uit een of meer gebruikersdatabases die zijn bedoeld om te werken als een gecoördineerde groep en die worden gerepliceerd op een aantal knooppunten in een cluster. Wanneer er een fout opgetreden is in het knooppunt of in de status van SQL Server op het knooppunt waarop de primaire kopie wordt gehost, wordt de groep databases verplaatst als een eenheid naar een ander replicaknooppunt in de AG. Alle gebruikersdatabases worden gesynchroniseerd over alle replica's van de beschikbaarheidsgroep, in een synchrone of asynchrone modus.

Dit werkt goed voor toepassingen die alleen met die set gebruikersdatabases werken, maar er zijn uitdagingen wanneer toepassingen ook afhankelijk zijn van objecten zoals gebruikers, aanmeldingen, machtigingen, agenttaken, enzovoort, die zijn opgeslagen in een van de systeemdatabases (master of msdb). Om de toepassingen soepel en voorspelbaar te laten functioneren, moet de beheerder handmatig ervoor zorgen dat wijzigingen in deze objecten worden gedupliceerd in alle replica-exemplaren in de beschikbaarheidsgroep. Als een nieuw exemplaar in de beschikbaarheidsgroep wordt gebracht, kunnen de databases automatisch of handmatig worden geseed in een eenvoudig proces, maar moeten alle aanpassingen van de systeemdatabase opnieuw worden geconfigureerd op het nieuwe exemplaar zodat deze overeenkomen met de andere replica's.

Ingesloten AGs breiden het concept uit van het repliceren van een groep databases om relevante delen van de master en msdb databases op te nemen. Denk hieraan als de uitvoeringscontext voor toepassingen die de ingesloten AG gebruiken. Het idee is dat de ingesloten AG-omgeving instellingen bevat die van invloed zijn op de toepassing die erop vertrouwt. Als zodanig heeft de ingesloten AG-omgeving betrekking op alle databases waarmee de toepassing communiceert, de verificatie die wordt gebruikt (aanmeldingen, gebruikers, machtigingen), geplande taken die worden verwacht uit te voeren en andere configuratie-instellingen die van invloed zijn op de toepassing.

Dit verschilt van ingesloten databases, die gebruikmaken van een ander mechanisme voor de gebruikersaccounts, waarbij de gebruikersgegevens in de database zelf worden opgeslagen. Ingesloten databases repliceren alleen aanmeldingen en gebruikers en het bereik van de gerepliceerde aanmelding of gebruiker is beperkt tot die individuele database (en de bijbehorende replica's).

In een ingesloten beschikbaarheidsgroep kunt u daarentegen op AG-niveau gebruikers, aanmeldingen, machtigingen enzovoort maken, en ze worden automatisch consistent in replica's in de AG, evenals consistent in databases binnen die AG. Hierdoor hoeft de beheerder deze wijzigingen niet handmatig aan te brengen.

SQL Server 2025-wijzigingen

Sql Server 2025 (17.x) Preview introduceert ondersteuning voor gedistribueerde beschikbaarheidsgroepen voor ingesloten beschikbaarheidsgroepen.

Verschillen

Er zijn enkele praktische verschillen waarmee u rekening moet houden bij het werken met ingesloten AG's, zoals het maken van ingesloten systeemdatabases en het afdwingen van de verbinding op het niveau van de ingesloten AG, in plaats van verbinding te maken op exemplaarniveau.

Ingesloten systeemdatabases

Elke ingesloten beschikbaarheidsgroep heeft eigen master en msdb systeemdatabases, genoemd naar de naam van de beschikbaarheidsgroep. In ingesloten AG-MyContainedAGhebt u bijvoorbeeld databases met de naam MyContainedAG_master en MyContainedAG_msdb. Deze systeemdatabases worden automatisch geseed naar nieuwe replica's en updates worden gerepliceerd naar deze databases, net als elke andere database in een beschikbaarheidsgroep. Dit betekent dat wanneer u een object zoals een login of agenttaak toevoegt terwijl deze is verbonden met de ingesloten AG, en de ingesloten AG een failover naar een ander exemplaar uitvoert, u nog steeds de agenttaken ziet en zich kunt authentiseren met behulp van de login die is gecreëerd in de ingesloten AG.

De systeemdatabases in een nieuw gemaakte ag zijn geen kopieën van het exemplaar waarop de opdracht CREATE AVAILABILITY GROUP wordt uitgevoerd. Ze zijn in eerste instantie lege sjablonen zonder gegevens. Onmiddellijk na de creatie worden de beheerdersaccounts op het exemplaar dat de ingesloten AG creëert, gekopieerd naar de ingesloten AG (master). Op die manier kan de beheerder zich aanmelden bij de ingesloten beschikbaarheidsgroep (AG) en de rest van de configuratie instellen.

Als u lokale gebruikers of configuraties in uw exemplaar maakt, worden ze niet automatisch weergegeven wanneer u de ingesloten systeemdatabases maakt, en zijn ze ook niet zichtbaar wanneer u verbinding maakt met de ingesloten beschikbaarheidsgroep. Zodra de gebruikersdatabase is toegevoegd aan een ingesloten beschikbaarheidsgroep, is deze onmiddellijk niet toegankelijk voor deze gebruikers. U moet ze handmatig opnieuw maken in de ingesloten systeemdatabases binnen de context van de ingesloten AG door rechtstreeks verbinding te maken met de database of door het listener-eindpunt te gebruiken. De uitzondering hierop is dat alle logins in de rol sysadmin in het bovenliggende exemplaar worden gekopieerd naar de nieuwe AG-specifieke master database tijdens het maken van een ingesloten AG.

Initiële gegevenssynchronisatie

De ingesloten systeemdatabases bieden alleen ondersteuning voor automatisch seeden als initiële manier voor gegevenssynchronisatie.

In SQL Server 2022 (16.x) en eerdere versies moeten ingesloten beschikbaarheidsgroepen automatische seeding gebruiken tijdens het maken. Wanneer u de CREATE AVAILABILITY GROUP instructie of de wizard Nieuwe beschikbaarheidsgroep in SQL Server Management Studio gebruikt, neemt u alleen gebruikersdatabases op die ondersteuning bieden voor automatisch seeden. Als u grote databases wilt toevoegen met behulp van handmatige seeding (JOIN ONLY), wacht u totdat de ingesloten AG is gemaakt.

In SQL Server 2025 (17.x) Preview gebruiken ingesloten systeemdatabases altijd automatische seeding, zelfs als de CREATE AVAILABILITY GROUP instructie handmatig seeding specificeert. U kunt de seedingmodus instellen op handmatig om een ingesloten beschikbaarheidsgroep te maken en later gebruikersdatabases toe te voegen met andere synchronisatiemethoden dan automatisch seeden.

Een ingesloten systeemdatabase herstellen

Volg deze stappen om back-ups van ingesloten systeemdatabases te herstellen:

1. Verwijder de ingesloten Availability Group.

2. Herstel de ingesloten master en msdb databases op de oorspronkelijke primaire replica van de ingesloten BESCHIKBAARHEIDSGROEP.

3. Verwijder de ingesloten master database en msdb uit secundaire replica's.

4. Maak op de primaire replica de gecontaineriseerde beschikbaarheidsgroep opnieuw aan met de oorspronkelijke naam en knooppunten, met de syntaxis WITH (CONTAINED, REUSE_SYSTEM_DATABASES) en SEEDING_MODE = AUTOMATIC.

Wanneer u een ingesloten beschikbaarheidsgroep opnieuw maakt, moet u geen ingesloten systeemdatabases opnemen in de CREATE AVAILABILITY GROUP instructie. SQL Server detecteert ze automatisch wanneer REUSE_SYSTEM_DATABASES wordt opgegeven. In SQL Server 2022 (16.x) en eerdere versies zijn alleen kleine gebruikersdatabases opgenomen die ondersteuning bieden voor automatisch seeden. Voeg grote databases afzonderlijk toe nadat de ingesloten beschikbaarheidsgroep is gemaakt, door JOIN ONLY te gebruiken.

Bevatte beschikbaarheidsgroepwerkzaamheden

Taken die deel uitmaken van een ingesloten beschikbaarheidsgroep worden alleen uitgevoerd op de primaire replica. Ze worden niet uitgevoerd op secundaire kopieën.

Verbinding maken (ingesloten omgeving)

Het is belangrijk om onderscheid te maken tussen het maken van verbinding met de instantie en het maken van verbinding met de bevatten AG. De enige manier om toegang te krijgen tot de omgeving van de ingesloten AG is om verbinding te maken met de ingesloten AG-listener of om verbinding te maken met een database die zich in de ingesloten AG bevindt.

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

Waar MyContainedDatabase een database is binnen de ingesloten AG waarmee u wilt interageren.

Dit betekent dat u een listener voor de ingesloten beschikbaarheidsgroep moet maken om effectief een ingesloten beschikbaarheidsgroep te kunnen gebruiken. Als u verbinding maakt met een van de exemplaren die als host fungeren voor de ingesloten AG in plaats van rechtstreeks naar de ingesloten AG via de listener te maken, bevindt u zich in de omgeving van het exemplaar en niet de ingesloten AG.

Als uw beschikbaarheidsgroep bijvoorbeeld MyContainedAG wordt gehost op de server SERVER\MSSQLSERVERen in plaats van verbinding te maken met de listener MyContainedAG_Listener, maakt u verbinding met het exemplaar met behulp van SERVER\MSSQLSERVER, bevindt u zich in de omgeving van het exemplaar en niet in de omgeving van MyContainedAG. Dit betekent dat u gebonden bent aan de inhoud (gebruikers, machtigingen, taken, enzovoort) die in de systeemdatabases van de instantie worden gevonden. Voor toegang tot de inhoud in de ingesloten systeemdatabases van de ingesloten AG maakt u in plaats daarvan verbinding met de ingesloten AG-listener (bijvoorbeeldMyContainedAG_Listener). Wanneer u bent verbonden met het exemplaar via de ingesloten AG-listener, wanneer u met mastercommuniceert, wordt u daadwerkelijk omgeleid naar de ingesloten master-database (bijvoorbeeld MyContainedAG_master).

Alleen-lezen routering en ingesloten beschikbaarheidsgroepen

Als u alleen-lezenroutering configureert om verbindingen met een leesintentie om te leiden naar een secundaire replica (zie Alleen-lezenroutering configureren voor een AlwaysOn-beschikbaarheidsgroep) en u verbinding wilt maken met behulp van een aanmelding die alleen in de ingesloten beschikbaarheidsgroep is gemaakt, zijn er enkele aanvullende overwegingen:

• U moet een database opgeven die deel uitmaakt van de contained AG in de verbindingsreeks
• De gebruiker die is opgegeven in de connectiestring, moet permissie hebben om toegang te krijgen tot de databases in de bevatte AG.

Bijvoorbeeld in de volgende verbindingsreeks, waarbij AdventureWorks een database is binnen de contained AG met MyContainedListeneren waarbij MyUser een gebruiker is die is gedefinieerd in de contained AG en niet in een van de deelnemende instanties:

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

Met deze verbindingsreeks maakt u verbinding met de leesbare secundaire die deel uitmaakt van de ReadOnly-routering configuratie, en bevindt u zich in de context van de ingesloten AG.

Verschillen tussen het maken van verbinding met het exemplaar en het maken van verbinding met de ingesloten beschikbaarheidsgroep

• Wanneer ze zijn verbonden met een ingesloten beschikbaarheidsgroep, zien gebruikers alleen databases in de ingesloten beschikbaarheidsgroep, plus tempdb.
• Op instantie-niveau zijn de ingesloten AG master en msdb namen [contained AG]_masteren [contained AG]_msdb. Binnen de ingesloten AG worden hun namen master en msdb.
• De database-id voor de ingesloten AG master is 1 vanuit de ingesloten AG, maar iets anders wanneer verbonden met het exemplaar.
• Hoewel gebruikers geen databases buiten de ingesloten AG in sys.databases zien wanneer ze verbonden zijn via een ingesloten AG-verbinding, kunnen ze toegang verkrijgen tot die databases met een driedelige naam of via de opdracht USE.
• Serverconfiguratie via sp_configure kan worden gelezen vanuit de bevatte AG-verbinding, maar kan alleen worden geschreven vanaf instantie-niveau.
• Vanuit ingesloten AG-verbindingen kan de systeembeheerder bewerkingen op exemplaarniveau uitvoeren, zoals het afsluiten van SQL Server.
• De meeste bewerkingen op databaseniveau, eindpuntniveau of AG-niveau kunnen alleen worden uitgevoerd vanuit exemplaarverbindingen, niet vanuit contained AG-verbindingen.

Interacties met andere functies

Er zijn aanvullende overwegingen bij het gebruik van bepaalde functies met ingesloten AG's en er zijn enkele functies die momenteel niet worden ondersteund.

Reservekopie maken

Procedures voor het maken van back-ups van databases in een ingesloten beschikbaarheidsgroep zijn hetzelfde als back-upprocedures voor gebruikersdatabases. Dit geldt voor zowel de ingesloten AG-gebruikersdatabases als de ingesloten AG-systeemdatabases.

Als de back-uplocatie lokaal is, worden de back-upbestanden op de server geplaatst waarop de back-uptaak wordt uitgevoerd. Dit betekent dat uw back-upbestanden zich mogelijk op verschillende locaties bevinden.

Als de back-uplocatie zich op een netwerkresource bevindt, hebben alle servers die replica's hosten toegang nodig tot die resource.

Gedistribueerde beschikbaarheidsgroepen

Een gedistribueerde beschikbaarheidsgroep is een speciaal type beschikbaarheidsgroep dat twee onderliggende beschikbaarheidsgroepen omvat. Wanneer u een gedistribueerde beschikbaarheidsgroep configureert, worden wijzigingen die zijn aangebracht op de globale primaire replica (de primaire replica van uw eerste AG) vervolgens gerepliceerd naar de primaire replica van uw tweede AG, ook wel de doorstuurreplica genoemd.

Vanaf SQL Server 2025 (17.x) Preview kunt u een gedistribueerde beschikbaarheidsgroep tussen twee ingesloten AG's configureren. Aangezien een ingesloten beschikbaarheidsgroep afhankelijk is van ingesloten master databases en msdb systeemdatabases, moet de tweede AG (doorstuurserver) dezelfde ingesloten AG-systeemdatabase hebben als de globale primaire.

Als u van plan bent om een ingesloten AG te gebruiken als doorstuureenheid in een gedistribueerde beschikbaarheidsgroep, moet u de ingesloten AG maken met behulp van de AUTOSEEDING_SYSTEM_DATABASES clausule voor de WITH | CONTAINED optie van de CREATE AVAILABILITY GROUP-instructie. De AUTOSEEDING_SYSTEM_DATABASES clausule vertelt SQL Server om het aanmaken van zijn eigen ingesloten AG-systeemdatabases over te slaan en in plaats daarvan de ingesloten AG-systeemdatabases vanuit de globale primaire te zaaien.

Resourcesbeheerder

In SQL Server 2022 (16.x) vóór cumulatieve update 18 en in oudere versies van SQL Server wordt het configureren of gebruiken van resource governor op ingesloten beschikbaarheidsgroepverbindingen niet ondersteund.

Vanaf SQL Server 2022 (16.x) Cumulatieve update 18, als u resource governor configureert voor een exemplaarverbinding, wordt het resourceverbruik voor exemplaarverbindingen of ingesloten beschikbaarheidsgroepverbindingen beheerd zoals verwacht. Als u resource governor probeert te configureren voor een ingesloten verbinding met een beschikbaarheidsgroep, krijgt u een foutmelding.

Resource governor werkt op 'Database Engine'-instantieniveau. Resource Governor-configuratie op exemplaarniveau wordt niet doorgegeven aan beschikbaarheidsreplica's. U moet resource governor configureren voor elk exemplaar dat als host fungeert voor een beschikbaarheidsreplica.

Zie Resource Governor en configuratievoorbeelden en best practices van Resource Governor voor meer informatie.

Gegevenswijzigingen vastleggen

Change Data Capture (CDC) wordt geïmplementeerd als SQL Agent-taken, dus de SQL Agent moet worden uitgevoerd op alle exemplaren met replica's in de ingesloten AG.

Als u wijzigingsgegevens vastleggen wilt gebruiken met een ingesloten AG, maakt u verbinding met de AG-listener wanneer u CDC configureert, zodat de CDC-metagegevens worden geconfigureerd door de ingesloten systeemdatabases te gebruiken.

Logboekverzending

Logboekverzending kan worden geconfigureerd als de brondatabase zich in de ingesloten beschikbaarheidsgroep (contained AG) bevindt. Een verzenddoel voor logboeken wordt echter niet ondersteund binnen een ingesloten AG. Daarnaast is er een extra stap voor het wijzigen van de taak voor het verzenden van logboeken nadat CDC is geconfigureerd.

Volg deze stappen om log shipping met een zelfstandige beschikbaarheidsgroep te configureren:

1. Maak verbinding met de ingesloten AG-listener.
2. Configureer logboekverzending zoals u dat normaal zou doen.
3. Nadat de logboekverzendingstaak is geconfigureerd, wijzigt u de taak om verbinding te maken met de ingesloten AG-listener voordat u een back-up maakt.

Transparent Data Encryption (TDE)

Als u TDE (Transparent Data Encryption) wilt gebruiken met databases in een ingesloten beschikbaarheidsgroep, installeert u de DATABASE Master Key (DMK) handmatig op de ingesloten master-database in de ingesloten BESCHIKBAARHEIDSGROEP.

Databases die gebruikmaken van TDE zijn afhankelijk van certificaten in de master-database om de DEK (Database Encryption Key) te ontsleutelen. Zonder dat certificaat kan SQL Server databases die zijn versleuteld met TDE niet ontsleutelen of online brengen. In een ingesloten beschikbaarheidsgroep controleert SQL Server beide master-databases op de DMK, de master-database voor het exemplaar en de ingesloten master-database binnen de beschikbaarheidsgroep om de database te ontsleutelen. Als het certificaat niet op een van beide locaties kan worden gevonden, kan SQL Server de database niet online brengen.

Als u de DMK wilt overdragen van de master-database van de instance naar de ingesloten master-database, raadpleegt u Een met TDE beveiligde database verplaatsen naar een andere SQL Server, met de nadruk op de gedeelten waar de DMK van de oude server naar de nieuwe wordt overgebracht.

SSIS-pakketten & onderhoudsplannen

Het gebruik van SSIS-pakketten, inclusief onderhoudsplannen, wordt niet ondersteund met ingesloten beschikbaarheidsgroepen.

Niet ondersteund

Momenteel worden de volgende SQL Server-functies niet ondersteund met een Contained Availability Group (CAG):

• SQL Server-replicatie van elk type (transactionele, samenvoeging, momentopname, enzovoort).
• Log shipping waarbij de doeldatabase zich in de gesloten AG bevindt. Logboekverzending met de brondatabase in de ingesloten beschikbaarheidsgroep wordt ondersteund.

DDL-wijzigingen

De enige DDL-wijzigingen bevinden zich in de CREATE AVAILABILITY GROUP workflow. Er is een WITH component met twee opties:

<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]

INGESLOTEN

Hiermee wordt aangegeven dat de te maken AG een ingesloten AG moet zijn.

HERGEBRUIK_SYSTEEM_DATABASES

De REUSE_SYSTEM_DATABASES optie is alleen geldig voor ingesloten AG's en geeft aan dat de zojuist gemaakte AG bestaande ingesloten systeemdatabases opnieuw moet gebruiken voor een eerdere ingesloten AG met dezelfde naam. Als u bijvoorbeeld een ingesloten beschikbaarheidsgroep met de naam MyContainedAGhebt en deze wilt verwijderen en opnieuw wilt maken, kunt u deze optie gebruiken om de inhoud van de oorspronkelijke ingesloten systeemdatabases opnieuw te gebruiken. Wanneer u deze optie gebruikt, geeft u geen systeemdatabasenamen op. SQL Server detecteert deze automatisch.

AUTOSEEDING_SYSTEM_DATABASES

Van toepassing op: SQL Server 2025 (17.x) Preview en hoger

Als u uw ingesloten beschikbaarheidsgroep wilt gebruiken als de doorstuurserver in een gedistribueerde beschikbaarheidsgroep, moet u de AUTOSEEDING_SYSTEM_DATABASES optie gebruiken wanneer u de ingesloten beschikbaarheidsgroep maakt . Deze optie geeft SQL Server de opdracht om het maken van eigen ingesloten AG-systeemdatabases over te slaan en in plaats daarvan de ingesloten AG-systeemdatabases te zaden van de globale primaire database.

DMV-wijzigingen

Er zijn twee toevoegingen aan DMV's met betrekking tot ingesloten AG's:

• De DMV-sys.dm_exec_sessions heeft een toegevoegde kolom: contained_availability_group_id
• De sys.availability_groups catalogusweergave bevat de toegevoegde kolom: is_contained

Verwante inhoud

• AANMAKEN AVAILABILITY GROUP (Transact-SQL)