News zu Microsoft SQL Server
Neuerungen wie der SQL Ledger oder die verbesserte Zusammenarbeit des SQL Server 2022 mit Microsoft Azure werden seitens Microsoft intensiv beworben. Allerdings verstecken sich unter der Haube des SQL Server 2022 noch andere coole und vor allem sehr nützliche Features. Eine wesentliche Verbesserung haben wir in unserem Beitrag “Was ist neu und nützlich am MS SQL Server 2022?” im vergangenen Jahr bereits kurz angerissen. Es geht um die Möglichkeit, Instanz-Konfigurationen an eine Availability Group zu binden. Damit kann die Gefahr, Konfigurationsarbeiten zu vergessen, erheblich reduziert werden. Im Microsoft SQL Server 2022 heißt diese ausgesprochen schicke Lösung “Contained Availability Groups”.
Wir sind der Meinung, dass viele SQL Server Admins (uns eingeschlossen) schon jahrelang auf diese Verbesserung gewartet haben und möchten heute ein bisschen tiefer in das Thema eintauchen. Wenn du also in der Vergangenheit schon mit Always On Availability Groups gearbeitet hast, solltest du dir die folgenden Zeilen nicht entgehen lassen.
Natürlich ist vielen Admins dieses Problem bewusst, was wiederum zu den erstaunlichsten Selfmade-Lösungen geführt hat, wie:
Letzten Endes läuft es darauf hinaus, dass die Inhalte einiger Systemtabellen manuell abgeglichen wurden. Man könnte von einer Art “Synchronisation durch Replikation” für Systemdatenbanken sprechen. Tatsächlich erfolgt ja eine Art Wiederholung auf den sekundären Replikaten. Wie man in jedem Falle sieht, war der Wunsch vieler Administratoren nach einer simplen Lösung für die Konfigurationsgleichheit aller Instanzen groß. Aus unserer Sicht absolut verständlich.
Microsoft hat sich dieser Thematik angenommen und eine ausgesprochen elegante Lösung entwickelt:Zunächst einmal sei gesagt, dass es sich um vollwertige Availability Groups handelt, so dass man keine lieb gewonnenen Eigenschaften verliert. Alle bekannten Fähigkeiten und Features, wie etwa automatisches Seeding oder die bevorzugten Replikate für Datenbank-Backups, sind enthalten.
Es handelt sich vielmehr um eine Erweiterung zur verbindungsabhängigen Instanzkonfiguration. Sofern man sich gezielt (sprich mittels AG-Listener) zur AG verbindet, erhält man gewissermaßen einen anderen Blick auf die Instanz. Der Clou dabei ist, dass die gewünschten Objekte mit der AG zusammen umziehen. Gewünschte Objekte können in dem Falle sein:
Das heißt also, eine Contained Availability Group kann dedizierte Konfigurationen der Instanz enthalten.
Die eigentliche Nutzerdatenbank, welche man in einer Contained Availability Group hochverfügbar betreiben will, wird nicht verändert. Die Methodik basiert vielmehr auf einer Art Layer-Prinzip, wie man es von Views auf Tabellen kennt. Und erneut: Es ist von entscheidender Bedeutung, dass man mit dem Listener der AG verbunden ist. Denn – und das ist der eigentliche Trick – im Hintergrund werden individuelle Exemplare der Systemdatenbanken erstellt. Diese legen sich anschließend transparent über die echten Systemdatenbanken und nehmen die gewünschten Konfigurationen auf. In der Konsequenz bedeutet dies, dass beispielsweise neu angelegte Konten (Anmeldungen/Logins) nicht tatsächlich in der Instanz erstellt werden, sondern stattdessen (durch Umleitung) in einer Art “Schatten-Systemdatenbank”. Und genau diese Datenbanken sind (von Beginn an) Mitglied der Contained Availability Group und wechseln daher bei jedem Failover mit. Das Verfahren ähnelt dabei einer Überlagerung. Verbindet man sich zum Listener der AG, so sieht man die individuellen System-Datenbanken, nicht die echten.
Zum besseren Verständnis:
Man könnte sagen, der SQL Server 2022 “schummelt” beim Anlegen von Anmeldungen. Neue Logins werden nicht in der echten master-Datenbank und neue SQL Server Agent Jobs nicht in der echten msdb-Datenbank abgelegt. Aber: Der Zweck heiligt die Mittel.
An der Verwaltung einer individuellen Instanz hat sich nichts geändert. Denn der Effekt wirkt nur dann, wenn man sich von Beginn an zum Listener der AG verbindet. Baut man hingegen eine Verbindung zu einer der individuellen Instanzen auf (ohne auf primäre und sekundäre Rollen der AGs zu achten), so bleibt alles beim Alten. Man arbeitet wie gewohnt mit den echten Systemdatenbanken.
Dazu hier eine kurze Gegenüberstellung. Stellt man sich eine simple Always On Umgebung aus zwei Teilnehmern …
1. Standardinstanz auf Host SERVER1
2. Standardinstanz auf Host SERVER2
… vor, welche gemeinsam eine Contained Availability Group namens ALWAYSON bilden, die wiederum den Listener HASERVER verwendet, und legt beispielsweise eine neue SQL-Anmeldung (ein Login) an …
CREATE LOGIN [TestAccount]
WITH PASSWORD = 'SimplePassword4Test!',
DEFAULT_DATABASE = [master],
DEFAULT_LANGUAGE = [English]; … so gilt:
bei Verbindung zu SERVER1
(dediziert)
[master]-Datenbank von Instanz SERVER1. bei Verbindung zu SERVER2
(dediziert)
[master]-Datenbank von Instanz SERVER2. bei Verbindung zu HASERVER
(als Listener der AG)
[master]-Datenbanken, sondern in den “Schattendatenbanken” der Contained Availability Group ALWAYSON, welche von der Synchronisation erfasst werden. Die Nutzung dieser Anmeldung ist nur im Kontext der Contained Availability Group möglich.
Somit ist sichergestellt, dass man ohne jegliche Umgewöhnung die einzelnen Instanzen verwalten kann. Gleichermaßen können Konfigurationsaspekte gewissermaßen an eine Availability Group gebunden werden, welche auf allen teilnehmenden Replikaten identisch sind. Und genau das ist schließlich auch das Schöne an dieser Implementierung.
Übrigens:
Jene Art der Einbindung geht sogar so weit, dass man nicht nur neue Sachen in den “Schattendatenbanken” anlegen kann. Es ist darüber hinaus möglich, vorhandene Konfigurationen zeitweilig zu überschreiben, indem man bereits existierende Objekte mit gleichnamigen überlagert. So funktioniert der zuvor beschriebene Trick nicht nur mit dem (neu anzulegenden) Konto “TestAccount”, sondern sogar mit dem ab Werk vorhandenen sa-Konto.
Zur Arbeit mit Contained Availability Groups gäbe es noch viel mehr zu schreiben. Doch der wichtigste Punkt ist klar: Sie sind eine zuverlässige Möglichkeit, um einzelne Instanzeigenschaften und ‑konfigurationen an einer Availability Group festzumachen. Somit wird die Konfigurationsgleichheit aller Instanzen sichergestellt.
Die neue Art der Contained Availability Groups ist ein höchst willkommener Schritt im Hinblick auf eine langfristig sinnvolle Nutzung des Availability Group Konzepts. Egal, ob man eine Datenbank in einer kleinen und schlichten Availability Group aus zwei Instanzen, oder 20 große Datenbanken in einer Distributed Availability Group aus vier Instanzen betreibt. Es lohnt sich allein schon wegen dieses Features, auf den Microsoft SQL Server 2022 zu wechseln.
Bei Fragen zur Arbeit mit den Contained Availability Groups oder zum Upgrade auf den Microsoft SQL Server 2022 helfen wir dir gern weiter.
Hier findest du weitere Beiträge rund um Microsoft aus unserem News & Insights Bereich.
Share this article