Always-On-Verfügbarkeitsgruppen unterstützen Nutzer*innen dabei, eine hohe Verfügbarkeit zu gewährleisten, Notfallwiederherstellung und Skalierungsausgleich zu bieten und die Verlässlichkeit und Geschwindigkeit eines Datenbanksystems zu erhöhen. Doch beim Einrichten und Bearbeiten einer Always-On-Verfügbarkeitsgruppe können Probleme auftreten. Mit diesen wollen wir uns in diesem Artikel beschäftigen.
Always on Availability Group Feature Not Enabled
Das erste Problem tritt auf, wenn man versucht, eine neue Always-On-Verfügbarkeitsgruppe aufzusetzen. Dies gelingt im Object Explorer von SQL Server Management Studio unter dem Punkt Always On High Availability. Dabei kann folgende Fehlermeldung auftreten:
The Always On Availability Groups feature must be enabled for server instance 'SQL1' before you can create an availability group on this instance. To enable this feature, open the SQL Server Configuration Manager, select SQL Server Services, right-click on the SQL Server service name, select Properties, and use the Always On Availability Groups tab of the Server Properties dialog. Enabling Always On Availability Groups may require that the server instance is hosted by a Windows Server Failover Cluster (WSFC) node. (Microsoft.SqlServer.Management.HadrTasks)
Es muss also sichergestellt werden, dass das Always On-Verfügbarkeitsgruppen-Feature auf jeder Instanz von SQL Server aktiviert ist, die an der Always On-Verfügbarkeitsgruppe beteiligt ist, bevor diese Gruppe erstellt wird.
Dieses Feature lässt sich leicht im Konfigurationsmanager von SQL Server aktivieren. Hier wählt man unter den SQL Serverdiensten die Datenbankengine aus und öffnet dazu die Eigenschaften.
Jetzt muss man zum AlwaysOn High Availability-Reiter navigieren und hier die entsprechende Option auswählen. Dabei ist zu beachten, dass SQL Server für die Aktivierung des Features neu gestartet werden muss.
Problem mit der Validierung der Datenbank-Prerequisites
Bei der Erstellung der Always On-Verfügbarkeitsgruppen muss man die Datenbanken spezifizieren, die an der Always On Verfügbarkeitsgruppe teilnehmen sollen. Bevor eine Datenbank hinzugefügt wird, wird geprüft, ob sie die Voraussetzungen dafür erfüllt. Tut sie das nicht, tritt die folgende Fehlermeldung auf:
To be added to an availability group, this database must be set to the full recovery model. Set the Recovery Model database property to Full and perform a full or differential database backup on the database. You will then need to schedule log backups on the database.
Die Datenbank muss also mit einem Full Recovery Model konfiguriert werden und es muss ein volles oder differentiertes Backup der Datenbank erstellt werden.
Das Programm erinnert auch daran, ein Transaktionslog-Backup für diese Datenbank einzuplanen, nachdem auf ein Full Recovery-Modell umgestellt wurde, um die Logdatei automatisch zu kürzen und zu verhindern, dass dieser Datei der Speicherplatz ausgeht.
Um dieses Problem zu lösen, muss das Recovery-Modell der Datenbank von Einfach auf Voll umgestellt werden. Diese Einstellung ist im Datenbankeigenschaftenmenü zu finden unter dem Punkt Optionen:
Nachdem die Einstellung geändert wurde und das Backup erstellt wurde, sollte man das Fenster zur Datenbankauswahl neu laden. Die Datenbank wird jetzt die Voraussetzungen erfüllen.
Problem mit dem Ort des geteilten Servers
Während der Einrichtung der Always On-Verfügbarkeitsgruppe, kann ein Problem bei der Validierung auftreten:
The primary server 'SQL1' cannot write to '\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak'. (Microsoft.SqlServer.Management.HadrModel)
Backup failed for Server 'SQL1'. (Microsoft.SqlServer.SmoExtended)
Cannot open backup device '\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak'. Operating system error 5(Access is denied.).
BACKUP DATABASE is terminating abnormally. (.Net SqlClient Data Provider)
Bei der Initialisierung wird ein Pfad angegeben, an der das Backup und die Logdaten gespeichert werden. Darauf greifen die sekundären Instanzen zu, um die Kopien der DBs entsprechend der Änderungen anzupassen. Wenn der Primärknoten nicht in diese Datei schreiben kann oder die Sekundären diese nicht auslesen können, schlägt die Validierung folgendermaßen fehl:
Dieses Problem lässt sich beheben, indem man dem SQL Server-Account der Primär- und Sekundärkopien Lese- und Schreibberechtigung zu dem Ordner gibt, der in der Fehlermeldung steht. Danach wird die Validierung erfolgreich durchlaufen.
Problem mit dem Windows Failover Cluster
Wenn man den Status einer bestehenden Always On-Verfügbarkeitsgruppe prüft, kann folgende Situation auftreten: Die primäre Rolle hat sich von SQL1 zu SQL2 verschoben, wobei die Datenbanken in SQL2 synchronisiert sind, in SQL1 jedoch nicht. Der Status von SQL1 wird als “Resolving” angegeben.
Im SQL Server Error Log des problematischen Knotens kann man sehen, dass die Kopie der Verfügbarkeitsgruppe offline gegangen ist und dass die Verfügbarkeitsgruppe nicht mehr funktioniert wegen eines Fehlers Im Windows Failover Clusters.
- Always On Availability Groups: Local Windows Server Failover Clustering node is no longer online. This is an informational message only. No user action is required.
- Always On: The availability replica manager is going offline because the local Windows Server Failover Clustering (WSFC) node has lost quorum. This is an informational message only. No user action is required.
- Always On: The local replica of the availability group 'DemoGroup' is stopping. This is an informational message only. No user action is required.
Das lässt sich auch am Windows Server Event Viewer ablesen, in dem man nachvollziehen kann, wie die Kopie sich in den “Resolving”-Zustand bewegt hat:
- Always On: The local replica of availability group 'DemoGroup' is preparing to transition to the resolving role. This is an informational message only. No user action is required.
- The availability group 'DemoGroup' is being asked to stop the lease renewal because the availability group is going offline. This is an informational message only. No user action is required.
- The state of the local availability replica in availability group 'DemoGroup' has changed from 'PRIMARY_NORMAL' to 'RESOLVING_NORMAL'. The state changed because the availability group is going offline. The replica is going offline because the associated availability group has been deleted, or the user has taken the associated availability group offline in Windows Server Failover Clustering (WSFC) management console, or the availability group is failing over to another SQL Server instance. For more information, see the SQL Server error log or cluster log. If this is a Windows Server Failover Clustering (WSFC) availability group, you can also see the WSFC management console.
Im Failover Cluster Manager sieht man, dass das ganze Cluster nicht mehr verfügbar ist, wie auf dem unteren Bild zu sehen:
Die erste Anlaufstelle ist der Cluster Service, der über die Windows Services-Seite aufgerufen wird:
Schon anhand der Menüpunkte ist klar, dass der Cluster Service nicht läuft. Um das Problem zu beheben, startet man den Dienst von in diesem Fenster und lädt dann den Failover Cluster Manager neu, um zu sehen, ob das Windows Cluster wieder online ist.
Auch in der Verfügbarkeitsgruppe kann man jetzt sehen, dass die Gruppe wieder synchronisiert ist.
