In diesem Artikel werden wir verschiedene Probleme erörtern, die beim Erstellen, Konfigurieren oder Verwalten einer Always On-Verfügbarkeitsgruppen-Site auftreten können.

Bevor Sie diesen Artikel lesen, sollten Sie den vorherigen Artikel, Einrichten und Konfigurieren von Always on-Verfügbarkeitsgruppen in SQL Server, lesen, um sich mit dem Konzept der Always on-Verfügbarkeitsgruppen und den in diesem Artikel gezeigten Assistenten für neue Verfügbarkeitsgruppen vertraut zu machen.

Always-on-Verfügbarkeitsgruppenfunktion nicht aktiviert

Angenommen, beim Versuch, eine neue Always On-Verfügbarkeitsgruppe zu erstellen, wurde im Objekt-Explorer von SQL Server Management Studio im Knoten „Always On High Availability“ die folgende Fehlermeldung angezeigt:

Die Funktion „AlwaysOn-Verfügbarkeitsgruppen“ muss für die Serverinstanz „SQL1“ aktiviert werden, bevor Sie eine Verfügbarkeitsgruppe auf dieser Instanz erstellen können. Um diese Funktion zu aktivieren, öffnen Sie den SQL Server-Konfigurations-Manager, wählen Sie SQL Server-Dienste aus, klicken Sie mit der rechten Maustaste auf den Namen des SQL Server-Diensts, wählen Sie Eigenschaften aus und verwenden Sie die Registerkarte Always On-Verfügbarkeitsgruppen des Dialogfelds Servereigenschaften. Das Aktivieren von Always On-Verfügbarkeitsgruppen erfordert möglicherweise, dass die Serverinstanz von einem Windows Server Failover Cluster (WSFC)-Knoten gehostet wird. (Microsoft.SqlServer.Management.HadrTasks)

Aus der Fehlermeldung geht hervor, dass das Feature „AlwaysOn-Verfügbarkeitsgruppen“ auf allen SQL Server-Instanzen aktiviert werden sollte, die Teil der Website „Always on-Verfügbarkeitsgruppe“ sind, bevor diese Website erstellt wird.

Sie können die Funktion „Always on Availability Group“ ganz einfach aktivieren, indem Sie die SQL Server Configuration Manager-Konsole öffnen, die Registerkarte „SQL Server-Dienste“ durchsuchen, dann mit der rechten Maustaste auf den Dienst „SQL Server Database Engine“ klicken und die Option „Eigenschaften“ auswählen.

Wechseln Sie im geöffneten Fenster SQL Server-Eigenschaften zur Registerkarte Always on High Availability und aktivieren Sie das Kontrollkästchen neben Always on Availability Group aktivieren , wobei zu berücksichtigen ist, dass diese Änderung einen Neustart des SQL Server-Dienstes erfordert, um wirksam zu werden, wie unten gezeigt:

Problem mit der Validierung der Datenbankvoraussetzungen

In den vorherigen Schritten des Assistenten für neue Verfügbarkeitsgruppen werden Sie aufgefordert, die Datenbank(en) anzugeben, die an der Always on-Verfügbarkeitsgruppe teilnehmen. Vor dem Hinzufügen der Datenbank sollte die Datenbank die Überprüfung der Voraussetzungen bestehen. Andernfalls kann die Datenbank nicht aus den Datenbanklisten ausgewählt werden, wie in der folgenden Fehlermeldung gezeigt:

Um einer Verfügbarkeitsgruppe hinzugefügt zu werden, muss diese Datenbank auf das vollständige Wiederherstellungsmodell eingestellt werden. Legen Sie die Datenbankeigenschaft des Wiederherstellungsmodells auf Vollständig fest und führen Sie eine vollständige oder differenzielle Datenbanksicherung für die Datenbank durch. Anschließend müssen Sie Protokollsicherungen für die Datenbank planen.

Die Botschaft ist klar. Wo die Datenbank mit einem vollständigen Wiederherstellungsmodell konfiguriert werden sollte und eine vollständige oder differenzielle Sicherung auf dieser Datenbank durchgeführt werden sollte.

Außerdem warnt Sie der Assistent davor, eine Transaktionsprotokollsicherung für diese Datenbank zu planen, nachdem Sie das Wiederherstellungsmodell auf „Vollständig“ geändert haben, um die Transaktionsprotokolldatei automatisch zu kürzen und zu verhindern, dass diese Transaktionsprotokolldatei über den freien Speicherplatz hinaus ausgeführt wird.

Um dieses Problem zu beheben, ändern Sie das Datenbankwiederherstellungsmodell auf der Registerkarte „Optionen“ des Datenbankeigenschaftenfensters von „Einfach“ in „Vollständig“ und erstellen Sie dann eine vollständige Sicherung von dieser Datenbank, wie unten gezeigt:

Beim Aktualisieren des Fensters „Datenbanken auswählen“ ändert sich der Datenbankstatus in „Voraussetzungen erfüllen“, wie unten gezeigt:

Problem mit der Berechtigung für den freigegebenen Netzwerkstandort

Beim Versuch, eine Always on-Verfügbarkeitsgruppen-Site zu konfigurieren, ist der Validierungsschritt des Assistenten für neue Verfügbarkeitsgruppen mit der folgenden Fehlermeldung fehlgeschlagen:

Der primäre Server „SQL1“ kann nicht in „\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak“ schreiben. (Microsoft.SqlServer.Management.HadrModel)

Sicherung für Server „SQL1“ fehlgeschlagen. (Microsoft.SqlServer.SmoExtended)

Das Sicherungsgerät '\\SQL1\AlwaysON\BackupLocDb_dbb55cb4-af89-4ed3-b189-1fcaad42358c.bak' kann nicht geöffnet werden. Betriebssystemfehler 5 (Zugriff verweigert.).

BACKUP DATABASE wird abnormal beendet. (.Net SqlClient-Datenanbieter)

Bei der anfänglichen Synchronisierungsmethode „Vollständige Datenbank- und Protokollsicherung“ ist ein freigegebener Ordner erforderlich, um die Sicherungsdateien der vollständigen Sicherung und des Transaktionsprotokolls vorübergehend aufzubewahren, um sie auf allen sekundären Replikaten wiederherzustellen. Wenn das primäre Replikat die Sicherungsdateien nicht darauf schreiben kann oder die sekundären Replikate die Sicherungsdateien nicht daraus lesen können, schlägt der Validierungsprozess für die neue Verfügbarkeitsgruppe wie folgt fehl:

Um dieses Problem zu beheben, müssen wir dem SQL Server-Dienstkonto der primären und sekundären Replikate Lese- und Schreibberechtigungen für den in der Fehlermeldung angezeigten freigegebenen Ordner erteilen und dann den Validierungsprozess erneut ausführen, um sicherzustellen, dass alle Prüfungen erfolgreich sind , wie unten gezeigt:

Windows-Failover-Cluster-Problem

Angenommen, Sie überprüfen den Status einer vorhandenen Website einer Always on-Verfügbarkeitsgruppe und sehen Sie Folgendes:

• Die primäre Rolle wird von der SQL1-Instanz auf die SQL2 verschoben.
• In SQL2 befinden sich die Datenbanken im synchronisierten Zustand.
• In SQL1 werden die Datenbanken nicht synchronisiert.
• SQL1 befindet sich im Auflösungsstatus.

Wie Sie im folgenden SSMS-Objekt-Explorer deutlich sehen können:

Beim Überprüfen der SQL Server-Fehlerprotokolle im problematischen Knoten sehen wir, dass das Replikat der Verfügbarkeitsgruppe offline ist und die Verfügbarkeitsgruppe aufgrund eines Problems im Windows Server-Failovercluster nicht mehr funktioniert, wie in den folgenden Fehlern gezeigt:

• Always On-Verfügbarkeitsgruppen:Lokaler Windows Server-Failover-Clustering-Knoten ist nicht mehr online . Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.
• Always On:Der Verfügbarkeitsreplikat-Manager wird offline geschaltet, weil der lokale Windows Server Failover Clustering (WSFC)-Knoten das Quorum verloren hat. Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.
• Always On:Das lokale Replikat der Verfügbarkeitsgruppe „DemoGroup“ wird angehalten. Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.

Das Gleiche kann aus der Windows Server-Ereignisanzeige erkannt werden, die schrittweise zeigt, wie das Replikat seinen Status in den Status „Resolving“ ändert, wie unten gezeigt:

• Always On:Das lokale Replikat der Verfügbarkeitsgruppe „DemoGroup“ bereitet den Übergang zur Auflösungsrolle vor . Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.
• Die Verfügbarkeitsgruppe „DemoGroup“ wird gebeten, die Lease-Verlängerung zu stoppen, weil die Verfügbarkeitsgruppe offline geht . Dies ist nur eine Informationsnachricht. Es ist keine Benutzeraktion erforderlich.
• Der Status des lokalen Verfügbarkeitsreplikats in der Verfügbarkeitsgruppe 'DemoGroup' hat sich von 'PRIMARY_NORMAL' in 'RESOLVING_NORMAL' geändert. Der Status hat sich geändert, weil die Verfügbarkeitsgruppe offline geht. Das Replikat wird offline geschaltet, weil die zugeordnete Verfügbarkeitsgruppe gelöscht wurde oder der Benutzer die zugeordnete Verfügbarkeitsgruppe in der Windows Server Failover Clustering (WSFC)-Verwaltungskonsole offline geschaltet hat oder die Verfügbarkeitsgruppe auf eine andere SQL Server-Instanz umgeleitet wird. Weitere Informationen finden Sie im SQL Server-Fehlerprotokoll oder im Clusterprotokoll. Wenn es sich um eine WSFC-Verfügbarkeitsgruppe (Windows Server Failover Clustering) handelt, können Sie auch die WSFC-Verwaltungskonsole sehen.

Um den Status der Windows-Cluster-Site zu überprüfen, verwenden wir den Failover-Cluster-Manager, um zu sehen, welcher Teil des Windows-Clusters ausfällt.

Aber der Failover-Cluster-Manager zeigt an, dass der gesamte Cluster ausgefallen ist, wie unten gezeigt:

Das erste, was hier von der Seite des Windows-Failoverclusters aus überprüft werden muss, ist der Clusterdienst, der wie folgt von der Windows-Dienstekonsole überprüft werden kann:

Aus der Dienstekonsole geht hervor, dass der Clusterdienst nicht ausgeführt wird. Um dieses Problem zu beheben, starten Sie den Dienst von dieser Konsole aus und aktualisieren Sie dann die Failover-Cluster-Manager-Konsole, um sicherzustellen, dass die Windows-Cluster-Site betriebsbereit ist, wie unten gezeigt:

Wenn Sie die Always on-Verfügbarkeitsgruppe erneut überprüfen, werden Sie sehen, dass die Datenbanken wieder synchronisiert sind und die Website der Always on-Verfügbarkeitsgruppe sich wieder im ordnungsgemäßen Zustand befindet, wie unten gezeigt:

Transaktionsprotokolldatei ist auf der Primärseite voll

Angenommen, Sie erhalten die folgende Fehlermeldung, wenn Sie versuchen, eine neue Abfrage für eine der Always on Availability Group-Datenbanken auszuführen:

Wenn Sie überprüfen, was die Transaktionsprotokolldatei blockiert und verhindert, dass sie abgeschnitten wird, werden Sie sehen, dass die Transaktionsprotokolldatei dieser Datenbank auf die Protokollsicherung wartet, um abgeschnitten zu werden, wie unten gezeigt:

Führen Sie wie folgt eine Transaktionsprotokollsicherung für diese Datenbank durch, falls Sie vergessen, einen Transaktionsprotokollsicherungsjob zu planen:

Und überprüfen Sie noch einmal, was das Transaktionsprotokoll dieser Datenbank blockiert, es zeigt in meinem Szenario, dass es auf Availability_Replica wartet. Dies bedeutet, dass die Protokolle darauf warten, in das sekundäre Replikat geschrieben zu werden, diese Transaktionsprotokolle jedoch aufgrund eines Problems auf der Website der Always On-Verfügbarkeitsgruppe nicht an die sekundären Replikate senden können, wie unten gezeigt:

Der beste Ort zum Überprüfen und Beheben von Fehlern auf der Website der Always on-Verfügbarkeitsgruppe ist das Always on-Dashboard, das geöffnet werden kann, indem Sie mit der rechten Maustaste auf den Namen der Verfügbarkeitsgruppe klicken und die Option Dashboard anzeigen auswählen.

Auf dem Dashboard können Sie sehen, dass das sekundäre Replikat SQL2 aufgrund von Verbindungsproblemen nicht mit dem primären Replikat synchronisiert ist, wie unten gezeigt:

Überprüfen Sie das sekundäre Replikat und stellen Sie sicher, dass der SQL Server-Dienst auf der sekundären Seite betriebsbereit ist und ausgeführt wird, wie folgt:

Wenn Sie dann das Verfügbarkeitsgruppen-Dashboard erneut aktualisieren, sehen Sie, dass die Website der Always on-Verfügbarkeitsgruppe wieder fehlerfrei ist. Checking if the transaction logs file is blocked by any operation, we will see that it is pending OLDEST_PAGE, indicating that the oldest page of the database is older than the checkpoint LSN. This issue can be fixed easily by taking another transaction log backup and the transaction log file will be blocked by nothing, as shown clearly below:

Always on Availability Group Failover Misconfiguration

Assume that the Primary replica becomes offline due to an unplanned issue. As expected, the system will not be affected as an automatic failover operation will be performed and the secondary replica will act as the new Primary replica.

But in our case, this happy scenario is not valid, where the secondary replica changed to Resolving state and the system is down!

Checking the secondary replica’s error log and see why it is not acting as the new Primary as expected, you will see that it is failing due to a role synchronization issue, as shown below:

The availability group database "AdventureWorks2017" is changing roles from "SECONDARY" to "RESOLVING" because the mirroring session or availability group failed over due to role synchronization. This is an informational message only. No user action is required.

This means that there is an issue with the synchronization mode that is used in this Availability Group. The synchronization mode used, can be checked from the Always on Availability Group properties page.

From the properties page below, it is clear that the Failover mode in this Availability Group is configured to be performed Manually only. In this case, you need to manually perform a failover operation before rebooting or shutting down the server:

This can be fixed easily by changing the Failover Mode to Automatic, where an automatic failover operation will be performed in case of any unplanned shutdown or reboot:

The same issue can be faced when the Windows Failover Cluster quorum is configured with Node Majority for an even number of replicas, where any failure for one of the servers will bring the Windows Failover Cluster site offline. For more information, check Windows Failover Cluster Quorum Modes in SQL Server Always On Availability Groups:

Failover with Data Loss

Assume that you are trying to perform a manual failover between the Primary and one of the Secondary replicas, but in the Select New Primary Replica window, you see a warning message that the failover operation may end up with data loss as the Primary and the selected Secondary replica are not synchronized, as shown below:

To identify the cause of that issue, we will browse the Always on Health events using the Always on Availability Group dashboard, which shows that the Primary replica is not able to open a connection to the Secondary replica, ash shown below:

After fixing the connectivity issue between the Primary and the Secondary, refresh the replicas list and you will see that the data loss issue is fixed, as shown below. For more information about troubleshooting the connectivity issues, check Troubleshoot connecting to the SQL Server Database Engine.

Monitoring Always on Availability Group Latency

The Availability Group dashboard can be modified to include additional columns that provide information about the synchronization latency between Primary and Secondary replicas, including the Commit LSN, Sent LSN and harden LSN values, without showing why there is a latency, as shown below:

For more information about measuring the latency, check the Measuring Availability Group synchronization lag.

Starting from SSMS 17.4, the Always on Availability Group dashboard enhanced to include two new options that are used for latency information calculation, analysis and reporting, which helps in identifying the bottlenecks in the transaction logs flow between the Primary and the Secondary replicas and narrow down the cause of that latency.
For more information about the new functionality and reports, check to Use the Always on Availability Group dashboard.

To trigger using this new option, click on Collect Latency Data option from the Always on Availability Group dashboard, that will create a new SQL Agent job on the Primary and Secondary replicas to collect the latency data, As shown below:

When the created job execution has completed on all the Availability Group replicas, you will be able to view the latency statistics from the latency reports by right-clicking on the Availability Group name and choose the Primary Replica Latency or Secondary Replica Latency report, based on the replica role in the Availability Group.

After providing information about the Availability Group replicas, the latency report will show a graphical view of the transaction log commit time on the Primary replica and the remote Hardening time for the secondary replicas, aggregated as average values. Also, the report provides statistical values for the transaction logs send, receive, commit, compress, decompress and other numerical values based on the replica role in the Availability Group.

For more information about the latency report, check New in SSMS - Always On Availability Group Latency Reports.

The below report is an example of the latency reports generated from the Secondary replica, showing normal logs transport operations:

Also, the Log Block Latency report shows the amount of time, in ms, that the transaction log on the Primary replica waits for Secondary replicas to commit that transaction. After enabling it from the Availability Group Dashboard, you can browse it from the SSMS similar to the previous latency reports. Take into consideration that, the large latency time indicates that the Primary replica is waiting a long time for the Secondary replicas to commit the sent transactions, as shown below: