Was ist eine eigenständige Verfügbarkeitsgruppe?

  • Artikel

Gilt für: SQL Server 2022 (16.x)

Eine enthaltene Verfügbarkeitsgruppe ist eine Always On-Verfügbarkeitsgruppe, die Folgendes unterstützt:

  • Verwalten von Metadatenobjekten (Benutzer, Anmeldungen, Berechtigungen, SQL-Agent-Aufträge usw.) auf Verfügbarkeitsgruppenebene zusätzlich zur Instanzebene.

  • Spezialisierte eigenständige Systemdatenbanken innerhalb der Verfügbarkeitsgruppe.

In diesem Artikel werden die Ähnlichkeiten, Unterschiede und Funktionen von eigenständigen Verfügbarkeitsgruppen erläutert.

Übersicht

Always On-Verfügbarkeitsgruppen bestehen in der Regel aus einer oder mehreren Benutzerdatenbanken, die als koordinierte Gruppe funktionieren sollen und in einigen Knoten in einem Cluster repliziert werden. Wenn es einen Fehler im Knoten oder bei der Integrität von SQL Server auf dem Knoten gibt, der die primäre Kopie hostet, wird die Datenbankgruppe als Einheit auf einen anderen Replikatknoten in der Verfügbarkeitsgruppe verschoben. Alle Benutzerdatenbanken werden in allen Replikaten der Verfügbarkeitsgruppe synchronisiert, entweder im synchronen oder im asynchronen Modus.

Dies funktioniert gut für Anwendungen, die nur mit dieser Gruppe von Benutzerdatenbanken interagieren. Schwierig kann es werden, wenn Anwendungen auch Objekte wie Benutzer, Anmeldungen, Berechtigungen, Agent-Aufträge usw. benötigen, die in einer der Systemdatenbanken gespeichert sind (master oder msdb). Damit die Anwendungen reibungslos und vorhersehbar funktionieren, müssen Administratoren manuell sicherstellen, dass Änderungen an diesen Objekten in allen Replikatinstanzen in der Verfügbarkeitsgruppe dupliziert werden. Wenn eine neue Instanz in die Verfügbarkeitsgruppe eingefügt wird, kann für die Datenbanken in einem einfachen Prozess automatisch oder manuell ein Seed ausgeführt werden. Dann müssen aber alle Anpassungen an den Systemdatenbanken auf der neuen Instanz neu konfiguriert werden, um den anderen Replikaten zu entsprechen.

Eigenständige Verfügbarkeitsgruppen erweitern das Konzept der Datenbankgruppe, bei dem die Datenbanken so repliziert werden, dass relevante Teile der Datenbanken master und msdb eingeschlossen sind. Stellen Sie sich das Ganze als Ausführungskontext für die Anwendungen vor, die die eigenständige Verfügbarkeitsgruppe verwenden. Der Gedanke dahinter: Die Umgebung einer eigenständigen Verfügbarkeitsgruppe enthält Einstellungen, die sich auf die Anwendungen auswirken, die die Verfügbarkeitsgruppe nutzt. Daher betrifft diese Umgebung alle Datenbanken, mit denen die Anwendung interagiert, die von der Anwendung verwendete Authentifizierung (Anmeldungen, Benutzer, Berechtigungen), alle geplanten Aufträge, die sie ausführen soll, sowie andere Konfigurationseinstellungen, die sich auf die Anwendung auswirken.

Dies ist ein Unterschied zu eigenständigen Datenbanken, die einen anderen Mechanismus für die Benutzerkonten verwenden und die Benutzerinformationen in der Datenbank selbst speichern. Eigenständige Datenbanken replizieren nur Anmeldeinformationen und Benutzer, und der Geltungsbereich einer replizierten Anmeldung oder eines replizierten Benutzers ist auf diese einzelne Datenbank (und ihre Replikate) beschränkt.

Im Gegensatz dazu können Sie in einer enthaltenen Verfügbarkeitsgruppe Benutzer, Anmeldungen und Berechtigungen auf Verfügbarkeitsgruppenebene erstellen, und diese sind automatisch in allen Replikaten in der Verfügbarkeitsgruppe sowie in allen Datenbanken innerhalb dieser enthaltenen Verfügbarkeitsgruppe konsistent. Dies erspart Administratoren die manuelle Eingabe all dieser Änderungen.

Unterschiede

Es gibt einige praktische Unterschiede, die beim Arbeiten mit eigenständigen Verfügbarkeitsgruppen zu berücksichtigen sind: Beispielsweise werden eigenständige Systemdatenbanken erstellt, und Verbindungen werden auf der Ebene der eigenständigen Verfügbarkeitsgruppe erzwungen, nicht auf Instanzebene hergestellt.

Eigenständige Systemdatenbanken

Jede eigenständige Verfügbarkeitsgruppe verfügt über eigene master- und msdb-Systemdatenbanken, deren Namen auf dem Namen der Verfügbarkeitsgruppe basieren. In der enthaltenen Verfügbarkeitsgruppe MyContainedAG gibt es beispielsweise Datenbanken mit den Namen MyContainedAG_master und MyContainedAG_msdb. Für diese Systemdatenbanken wird automatisch ein Seed auf neuen Replikaten ausgeführt, und Updates werden an diese Datenbanken repliziert, genau wie bei alle anderen Datenbanken in einer Verfügbarkeitsgruppe. Das bedeutet Folgendes: Wenn Sie bei bestehender Verbindung mit einer eigenständigen Verfügbarkeitsgruppe ein Objekt – z. B. eine Anmeldung oder einen Agent-Auftrag – hinzufügen und für die Verfügbarkeitsgruppe ein Failover auf eine andere Instanz durchgeführt wird, können Sie beim Herstellen einer Verbindung mit der eigenständigen Verfügbarkeitsgruppe weiterhin die Agent-Aufträge sehen und sich mit der Anmeldung authentifizieren, die in der eigenständigen Verfügbarkeitsgruppe erstellt wurde.

Wichtig

Eigenständige Verfügbarkeitsgruppen sind ein Mechanismus, durch den die Konfigurationen der Ausführungsumgebung in den Replikaten einer Verfügbarkeitsgruppe konsistent bleiben. Sie stellen keine Sicherheitsgrenze dar. Es gibt keine Grenze, die verhindert, dass beispielsweise eine Verbindung zu einer eigenständigen Verfügbarkeitsgruppe auf Datenbanken außerhalb der Verfügbarkeitsgruppe zugreift.

Die Systemdatenbanken in einer neu erstellten eigenständigen Verfügbarkeitsgruppe sind keine Kopien von der Instanz, in der der Befehl CREATE AVAILABILITY GROUP ausgeführt wird. Sie sind zunächst leere Vorlagen ohne Daten. Unmittelbar nach der Erstellung werden die Administratorkonten der Instanz, die die eigenständige Verfügbarkeitsgruppe erstellt, in die eigenständige master-Datenbank kopiert. Auf diese Weise können Administratoren sich bei der eigenständigen Verfügbarkeitsgruppe anmelden und den Rest der Konfiguration einrichten.

Wenn Sie lokale Benutzer oder Konfigurationen in Ihrer Instanz erstellt haben, werden diese nicht automatisch angezeigt, wenn Sie Ihre eigenständigen Systemdatenbanken erstellen, und sie werden nicht angezeigt, wenn Sie eine Verbindung mit der eigenständigen Verfügbarkeitsgruppe herstellen. Sobald die Benutzerdatenbank mit einer eigenständigen Verfügbarkeitsgruppe verknüpft wurde, wird sie für die entsprechenden Benutzer*innen sofort unzugänglich. Sie müssen sie in den eigenständigen Systemdatenbanken im Kontext der eigenständigen Verfügbarkeitsgruppe manuell neu erstellen, indem Sie eine direkte Verbindung zur Datenbank herstellen oder den Listener-Endpunkt verwenden. Ausnahme: Alle Anmeldungen der sysadmin-Rolle in der übergeordneten Instanz werden die neue master-Datenbank für die Verfügbarkeitsgruppe kopiert.

Eine eigenständige Systemdatenbank wiederherstellen

Sie können eine eigenständige Systemdatenbank mit einer der beiden folgenden Methoden wiederherstellen.

  • Wiederherstellen einer eigenständigen Datenbank mithilfe eines sekundären Replikats:

    1. Stellen Sie die eigenständige master- und msdb-Datenbank auf einer Serverinstanz wieder her, die das sekundäre Replikat hostet, wobei RESTORE WITH NORECOVERY für jeden Wiederherstellungsvorgang verwendet wird. Weitere Informationen finden Sie unter Vorbereiten einer sekundären Datenbank auf eine Always-On-Verfügbarkeitsgruppe.

    2. Verknüpfen Sie jede eigenständige Datenbank mit der Verfügbarkeitsgruppe. Weitere Informationen finden Sie unter Verknüpfen einer sekundären Datenbank mit einer Always-On-Verfügbarkeitsgruppe.

  • Wiederherstellen einer eigenständigen Datenbank durch Ablegen der eigenständigen Verfügbarkeitsgruppe:

    1. Legen Sie die eigenständige Verfügbarkeitsgruppe ab.

    2. Stellen Sie die eigenständige master- und msdb-Datenbank in jeder der Instanzen wieder her, die an der eigenständigen Verfügbarkeitsgruppe teilnehmen.

    3. Erstellen Sie die eigenständige Verfügbarkeitsgruppe mit ursprünglichen Knoten und Namen unter Verwendung der WITH (CONTAINED, REUSE_SYSTEM_DATABASES)-Syntax neu.

Herstellen einer Verbindung (eigenständige Umgebung)

Wichtig: Es gibt einen Unterschied zwischen dem Herstellen einer Verbindung mit der Instanz und dem Herstellen einer Verbindung mit der eigenständigen Verfügbarkeitsgruppe. Die einzige Möglichkeit für den Zugriff auf die Umgebung der eigenständigen Verfügbarkeitsgruppe besteht darin, eine Verbindung mit dem Listener der eigenständigen Verfügbarkeitsgruppe herzustellen oder eine Verbindung mit einer Datenbank herzustellen, die sich in der eigenständigen Verfügbarkeitsgruppe befindet.

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

Dabei ist MyContainedDatabase eine Datenbank innerhalb der eigenständigen Verfügbarkeitsgruppe, mit der Sie interagieren möchten.

Das bedeutet, dass Sie einen Listener für die eigenständige Verfügbarkeitsgruppe erstellen müssen, um diese effektiv zu verwenden. Wenn Sie eine Verbindung mit einer der Instanzen herstellen, die die eigenständige Verfügbarkeitsgruppe hosten, anstatt eine direkte Verbindung mit der eigenständigen Verfügbarkeitsgruppe über den Listener herzustellen, befinden Sie sich in der Umgebung der Instanz, nicht in der eigenständigen Verfügbarkeitsgruppe.

Ein Beispiel: Wenn Ihre Verfügbarkeitsgruppe MyContainedAG auf dem Server SERVER\MSSQLSERVERgehostet wird und Sie keine Verbindung mit dem Listener MyContainedAG_Listener, sondern mithilfe von SERVER\MSSQLSERVER eine Verbindung mit der Instanz herstellen, befinden Sie sich in der Umgebung der Instanz und nicht in der Umgebung von MyContainedAG. Dies bedeutet, dass Sie nur die Inhalte (Benutzer, Berechtigungen, Aufträge usw.) sehen, die in den Systemdatenbanken der Instanz enthalten sind. Um auf die Inhalte der eigenständigen Systemdatenbanken der eigenständigen Verfügbarkeitsgruppe zuzugreifen, stellen Sie stattdessen eine Verbindung mit dem Listener der eigenständigen Verfügbarkeitsgruppe her (z. B. MyContainedAG_Listener). Wenn Sie über den Listener der eigenständigen Verfügbarkeitsgruppe mit der Instanz verbunden sind, werden Sie bei Interaktionen mit master in Wirklichkeit an die eigenständige master-Datenbank umgeleitet (z. B. „MyContainedAG_mastermaster“).

Schreibgeschütztes Routing und eigenständige Verfügbarkeitsgruppen

Wenn Sie das schreibgeschützte Routing zum Umleiten von Verbindungen mit Leseabsicht an ein sekundäres Replikat konfiguriert haben (siehe Konfigurieren des schreibgeschützten Routings für eine Always On-Verfügbarkeitsgruppe) und zur Verbindungsherstellung eine Anmeldung verwenden möchten, die nur in der eigenständigen Verfügbarkeitsgruppe erstellt wurde, gibt es einige weitere Überlegungen:

  • Sie müssen in der Verbindungszeichenfolge eine Datenbank angeben, die Teil der eigenständigen Verfügbarkeitsgruppe ist.
  • Der in der Verbindungszeichenfolge angegebene Benutzer muss über die Berechtigung zum Zugriff auf die Datenbanken in der eigenständigen Verfügbarkeitsgruppe verfügen.

Beispiel: In der folgenden Verbindungszeichenfolge ist AdventureWorks eine Datenbank in der eigenständigen Verfügbarkeitsgruppe mit MyContainedListener. AdventureWorksMyUser ist ein Benutzer, der in der eigenständigen Verfügbarkeitsgruppe definiert ist, aber in keiner der teilnehmenden Instanzen:

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

Mit dieser Verbindungszeichenfolge wird eine Verbindung mit dem lesbaren sekundären Replikat hergestellt, das Teil der ReadOnly Routing-Konfiguration ist, und Sie befinden sich im Kontext der eigenständigen Verfügbarkeitsgruppe.

Unterschiede zwischen dem Herstellen einer Verbindung mit der Instanz und dem Herstellen einer Verbindung mit der eigenständigen Verfügbarkeitsgruppe

  • Bei einer Verbindung mit einer eigenständigen Verfügbarkeitsgruppe sehen Benutzer nur die Datenbanken der eigenständigen Verfügbarkeitsgruppe sowie tempdb.
  • Auf Instanzebene lauten die Namen der eigenständigen Verfügbarkeitsgruppe master und msdb [contained AG]_master und [contained AG]_msdb. Innerhalb der eigenständigen Verfügbarkeitsgruppe lauten die Namen master und msdb.
  • Die Datenbank-ID für die master-Datenbank der eigenständigen Verfügbarkeitsgruppe lautet innerhalb der eigenständigen Verfügbarkeitsgruppe 1. Bei einer Verbindung mit der Instanz lautet die ID anders.
  • Benutzer sehen zwar keine Datenbanken außerhalb der eigenständigen Verfügbarkeitsgruppe in sys.databases, wenn sie über eine eigenständigen Verfügbarkeitsgruppe verbunden sind, aber sie können mithilfe eines dreiteiligen Namens oder über den Befehl USE auf diese Datenbanken zugreifen.
  • Die Serverkonfiguration sp_configure kann über die Verbindung mit der eigenständigen Verfügbarkeitsgruppe gelesen werden, Schreibvorgänge sind jedoch nur auf Instanzebene möglich.
  • Über Verbindungen mit eigenständigen Verfügbarkeitsgruppen können Systemadministratoren Vorgänge auf Instanzebene ausführen, z. B. Herunterfahren von SQL Server.
  • Die meisten Vorgänge auf Datenbank-, Endpunkt- oder Verfügbarkeitsgruppenebene können nur über Instanzverbindungen ausgeführt werden, nicht über Verbindungen mit eigenständigen Verfügbarkeitsgruppen.

Interaktionen mit anderen Features

Bei der Verwendung bestimmter Features mit eigenständigen Verfügbarkeitsgruppen sind einige weitere Überlegungen zu berücksichtigen, und es gibt einige Features, die derzeit nicht unterstützt werden.

Nicht unterstützt

Derzeit werden die folgenden SQL Server-Features bei eigenständigen Verfügbarkeitsgruppen nicht unterstützt:

  • SQL Server-Replikationen jeder Art (Transaktion, Merge, Momentaufnahme usw.).
  • Verteilte Verfügbarkeitsgruppen.
  • Protokollversand, bei dem sich die Zieldatenbank in der eigenständigen Verfügbarkeitsgruppe befindet. Wenn sich die Quelldatenbank in der eigenständigen Verfügbarkeitsgruppe befindet, wird der Protokollversand unterstützt.

Erfassung geänderter Daten

Change Data Capture (CDC) wird in Form von SQL-Agent-Aufträgen implementiert, sodass der SQL-Agent auf allen Instanzen mit Replikaten in der eigenständigen Verfügbarkeitsgruppe ausgeführt werden muss.

Um CDC mit einer eigenständigen Verfügbarkeitsgruppe zu verwenden, stellen Sie eine Verbindung mit dem Verfügbarkeitsgruppenlistener her, wenn Sie CDC konfigurieren, sodass die CDC-Metadaten unter Verwendung der eigenständigen Systemdatenbanken konfiguriert werden.

Protokollversand

Der Protokollversand kann konfiguriert werden, wenn sich die Quelldatenbank in der eigenständigen Verfügbarkeitsgruppe befindet. Protokollversandziele werden in eigenständigen Verfügbarkeitsgruppen jedoch nicht unterstützt. Darüber hinaus muss ein zusätzlicher Schritt ausgeführt werden, um den Protokollversandauftrag zu ändern, nachdem CDC konfiguriert wurde.

Führen Sie die folgenden Schritte aus, um den Protokollversand mit einer eigenständigen Verfügbarkeitsgruppe zu konfigurieren:

  1. Stellen Sie eine Verbindung mit dem Listener der eigenständigen Verfügbarkeitsgruppe her.
  2. Konfigurieren Sie den Protokollversand wie sonst auch.
  3. Nach der Konfiguration des Protokollversandauftrags ändern Sie den Auftrag so, dass eine Verbindung mit dem Listener der eigenständigen Verfügbarkeitsgruppe hergestellt wird, bevor Sie eine Sicherung ausführen.

Transparent Data Encryption (TDE)

Um Transparent Data Encryption (TDE) mit Datenbanken in einer eigenständigen Verfügbarkeitsgruppe zu verwenden, installieren Sie den Datenbankhauptschlüssel (Database Master Key, DMK) manuell in der eigenständigen master-Datenbank innerhalb der eigenständigen Verfügbarkeitsgruppe.

Datenbanken, die TDE verwenden, benötigen Zertifikate in der master-Datenbank, um den Datenbankverschlüsselungsschlüssel (Database Encryption Key, DEK) zu entschlüsseln. Ohne dieses Zertifikat kann SQL Server mit TDE verschlüsselte Datenbanken nicht entschlüsseln oder online schalten. In einer eigenständigen Verfügbarkeitsgruppe überprüft SQL Server beide master-Datenbanken auf den DMK sowie die master-Datenbank für die Instanz und die eigenständige master-Datenbank in der eigenständigen Verfügbarkeitsgruppe, um die Datenbank zu entschlüsseln. Wenn das Zertifikat an keinem Speicherort gefunden wird, kann SQL Server die Datenbank nicht online schalten.

Informationen zum Übertragen des DMK aus der master-Datenbank der Instanz in die eigenständige master-Datenbank finden Sie im Artikel Verschieben einer TDE-geschützten Datenbank zu einer anderen SQL Server, in dem es hauptsächlich um die Phasen geht, in denen der DMK von einem alten auf einen neuen Server übertragen wird.

SSIS-Pakete und Wartungspläne

Die Verwendung von SSIS-Paketen, einschließlich Wartungsplänen, wird für enthaltene Verfügbarkeitsgruppen nicht unterstützt.

DDL-Änderungen

Die einzigen DDL-Änderungen befinden sich im CREATE AVAILABILITY GROUP-Workflow. Es gibt zwei neue WITH-Klauseln:

<with_option_spec> ::=
CONTAINED |
REUSE_SYSTEM_DATABASES

CONTAINED

Dies gibt an, dass die zu erstellende Verfügbarkeitsgruppe eine eigenständige Verfügbarkeitsgruppe sein soll.

REUSE_SYSTEM_DATABASES

Diese Option gilt nur für eigenständige Verfügbarkeitsgruppen und gibt an, dass die neu erstellte Verfügbarkeitsgruppe vorhandene eigenständige Systemdatenbanken einer vorherigen eigenständigen Verfügbarkeitsgruppe desselben Namens wiederverwenden soll. Wenn Sie z. B. eine eigenständige Verfügbarkeitsgruppe mit dem Namen MyContainedAG hatten und diese löschen und neu erstellen möchten, können Sie diese Option verwenden, um den Inhalt der ursprünglichen eigenständigen Systemdatenbanken wiederzuverwenden.

DMV-Änderungen

Es gibt zwei Ergänzungen zu dynamischen Verwaltungssichten (Dynamic Management Views, DMVs) im Zusammenhang mit eigenständigen Verfügbarkeitsgruppen:

  • Die DMV sys.dm_exec_sessions verfügt über eine hinzugefügte Spalte: contained_availability_group_id
  • Der Katalogansicht sys.availability_groups wurde eine Spalte hinzugefügt: is_contained

Zugehöriger Inhalt