Problembehandlung bei einer Verfügbarkeitsgruppendatenbank im wiederherstellenden Zustand

In diesem Artikel erfahren Sie, wie Sie Probleme mit einer Verfügbarkeitsgruppendatenbank im wiederherstellenden Zustand beheben.

Was ist der Wiederherstellenzustand?

Der Zustand wird wiederhergestellt, wenn der sekundäre Server änderungen rückgängig machen muss, die er bereits angewendet hat, um wieder mit dem primären Server synchronisiert zu werden.

Primäre und sekundäre Replikate der Verfügbarkeitsgruppe bleiben während des normalen Betriebs in einem verbundenen Zustand, sodass Änderungen am primären Replikat aktiv mit den sekundären Replikaten synchronisiert werden.

Während eines Failovers wird dieser Verbindungsstatus getrennt. Sobald das neue primäre Replikat online geschaltet ist, wird die Konnektivität zwischen dem primären Replikat und den sekundären Replikaten wiederhergestellt. Während dieses anfänglichen Verbindungszustands wird ein gemeinsamer Wiederherstellungspunkt ausgehandelt, in dem die neue sekundäre Instanz die Wiederherstellung starten sollte, damit sie mit dem primären Server synchronisiert wird.

Wenn zum Zeitpunkt des Failovers eine große Transaktion ausgeführt wird, liegt das protokoll der neuen sekundären Datenbank vor der primären Replikatdatenbank. Der neue gemeinsame Wiederherstellungspunkt, der ausgehandelt wird, erfordert, dass das sekundäre Replikat Seiten vom primären Replikat empfängt, damit es sich in einem Zustand befindet, in dem die Synchronisierung fortgesetzt werden kann. Der Wiederherstellenprozess wird auch als "Rückgängig des Wiederholens" bezeichnet.

Der Wiederherstellenprozess ist inhärent langsam, tritt häufig auf, und in der Regel werden kleine Transaktionen, die den Wiederherstellen des Zustands auslösen, kaum bemerkt. Die Wiederherstellung des Zustands wird häufig bemerkt, wenn ein Failover eine große Transaktion unterbricht, wodurch viele Seiten vom primären zum sekundären Replikat gesendet werden, um die sekundäre Replikatdatenbank in einen wiederherstellbaren Zustand zu rückgängig machen.

Symptome und Auswirkungen einer Verfügbarkeitsgruppendatenbank im wiederherstellenden Zustand

Wenn sich eine Datenbank im wiederhergestellten Zustand auf dem sekundären Replikat befindet, wird die Datenbank nicht synchronisiert und empfängt daher keine Änderungen vom primären Replikat. Ein plötzlicher Verlust der Datenbank auf dem primären Replikat kann zu Datenverlusten führen.

Always On Dashboard berichte nicht synchronisiert auf dem primären Server

Nach dem Ausführen eines Failovers für eine Verfügbarkeitsgruppe stellen Sie möglicherweise fest, dass die sekundäre Gruppe nicht synchronisiert wird, während das Failover erfolgreich war. Die Always On Dashboard meldet Nicht synchronisiert auf dem primären und Wiederherstellen auf dem sekundären.

Always On Dashboard berichte nicht synchronisiert auf dem primären Server	Always On Dashboard meldet Wiederherstellen auf dem sekundären

Always On DMVs-Berichte WERDEN NICHT AUF dem primären Computer synchronisiert

Wenn Sie die folgenden Always On Dynamische Verwaltungssichten (Dynamic Management Views, DMVs) für Verfügbarkeitsgruppen (AGs) für das primäre Replikat abfragen, befindet sich die Datenbank im Zustand NOT SYNCHRONIZING.

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

Wenn Sie die DMVs auf der sekundären Datenbank abfragen, befindet sich die Verfügbarkeitsgruppendatenbank im Zustand WIEDERHERSTELLEN .

Schreibgeschützte Workloads und Berichtsworkloads können nicht auf die sekundäre Datenbank zugreifen

Während die sekundäre Datenbank wiederhergestellt wird, kann nicht darauf zugegriffen oder abgefragt werden. Diese schreibgeschützten Workloads sind offline und unterbrochen. Je nachdem, wie lange sich die Datenbank im wiederhergestellten Zustand befindet, kann es erforderlich sein, diese Workloads an ein anderes sekundäres Replikat oder das primäre Replikat umzuleiten, wenn diese Workloads unternehmenskritisch sind.

Wenn Sie über eine schreibgeschützte Workload verfügen, z. B. eine Berichtsworkload, die an das sekundäre Replikat weitergeleitet wird, können diese Batches mit der Meldung 922 fehlschlagen:

Msg 922, Ebene 14, Status 1, Zeile 2 Die Datenbank "agdb" wird wiederhergestellt. Warten, bis die Wiederherstellung abgeschlossen ist.

Eine Anwendung, die versucht, sich bei der sekundären Replikatdatenbank im wiederhergestellten Zustand anzumelden, kann keine Verbindung herstellen und löst den Fehler 18456 aus:

2023-01-26 13:01:13.100 Anmeldefehler: 18456, Schweregrad: 14, Status: 38. 2023-01-26 13:01:13.100 Anmeldefehler für Benutzer "UserName>"<. Ursache: Fehler beim Öffnen der explizit angegebenen Datenbank "agdb". [CLIENT: <lokaler Computer>]

Dieser Fehler kann auch im SQL Server Fehlerprotokoll gemeldet werden, wenn fehlgeschlagene Anmeldungen überwacht werden.

Schätzen der verbleibenden Zeit im Wiederherstellungszustand

Verwenden Sie eine der folgenden Methoden, um die verbleibende Zeit im Wiederherstellungszustand zu schätzen:

Verwenden der AlwaysOn_health XEvent-Sitzung

Das AlwaysOn_health erweiterte Ereignisdiagnoseprotokoll verfügt über ein hadr_trace_message-Ereignis , das alle fünf Minuten den Statusstatus wiederhergestellt.

Stellen Sie eine Verbindung mit dem sekundären Replikat her, indem Sie SQL Server Management Studio (SSMS) Objekt-Explorer und einen Drilldown zu Verwaltung, erweiterten Ereignissen und dann Sitzungen ausführen. Klicken Sie mit der rechten Maustaste auf das ereignis AlwaysOn_health , und wählen Sie Livedaten überwachen aus. Sie sollten ein neues Fenster im Registerkartenformat erhalten, das den aktuellen Status des Wiederherstellens des Vorgangs meldet. Der Zustand wird alle fünf Minuten über das hadr_trace_message -Ereignis gemeldet, und der abgeschlossene Prozentsatz des Wiederherstellungsvorgangs wird gemeldet.

Hinweis

Das erweiterte Ereignis hadr_trace_message wurde den neuesten kumulativen Updates in SQL Server 2019 und höher hinzugefügt. Sie müssen die neuesten kumulativen Updates ausführen, um dieses erweiterte Ereignis in der AlwaysOn_health erweiterten Ereignissitzung zu beobachten.

Das SQL Server Fehlerprotokolls auf dem sekundären Replikat ist bei der Schätzung des Wiederherstellens des Abschlusses nicht sehr hilfreich. In der folgenden Abbildung können Sie von 10:08 bis 11:03 Uhr beobachten, während im wiederherstellenden Zustand wenig gemeldet wird. Nachdem das sekundäre Replikat alle Seiten vom primären Replikat empfangen hat, kann es nun ein Rollback für die Transaktion ausführen, die auf dem ursprünglichen primären Replikat ausgeführt wurde, das den Wiederherstellen des Zustands ausgelöst hat. Die Wiederherstellung wird von 11:03 bis 11:05 Uhr ausgeführt. Kurz nach Abschluss der Wiederherstellung sollte die Datenbank mit der Synchronisierung mit dem primären Replikat beginnen und alle Änderungen auf dem primären Replikat aufholen, während sich die sekundäre Datenbank im wiederherstellenden Zustand befand.

Überwachen des Wiederherstellens der Abschlusszeit mithilfe von Leistungsmonitor

Überwachen Sie den Status der Wiederherstellung mithilfe der Leistungsindikatoren SQL Server:D atabase Replica:Total Log Requiring Undo and SQL Server:D atabase Replica:Log Remaining for Undo, und wählen Sie die Verfügbarkeitsgruppendatenbank für die Instanz aus. Im Beispiel im folgenden Screenshot wird " Total Log Requiring Undo " als 56,3 mb gemeldet, und "Log Remaining for Undo " wird langsam auf 0 ( 0 ) zurückgesetzt, der den Status der Wiederherstellung meldet.

Was sind Ihre anderen Optionen als warten?

Microsoft empfiehlt, die Zeit für den Abschluss des Wiederherstellens des Zustands zu schätzen.

Hinzufügen eines sekundären Replikats zu einer Verfügbarkeitsgruppe

Wenn nur zwei Replikate in der Verfügbarkeitsgruppe vorhanden sind, fügen Sie nach Möglichkeit ein weiteres sekundäres Replikat hinzu, das Hochverfügbarkeit und Redundanz bieten kann, und eine aktive Synchronisierung mit dem primären Replikat durchführen, während das andere sekundäre Replikat die Wiederherstellung abgeschlossen hat.

Wichtig

Führen Sie kein Failover auf ein Replikat durch, dessen Datenbanken sich im zustand "wiederherstellen" befinden. Dies kann zu einer nicht verwendbaren Datenbank führen, die eine Wiederherstellung aus einer Sicherung erfordert. Starten Sie das sekundäre Replikat nicht neu, instance. Dadurch wird dieser Prozess nicht beschleunigt und kann den Zustand der sekundären Replikatdatenbank beeinträchtigen, die sich im wiederhergestellten Zustand befindet.

Behandeln fehlerhafter schreibgeschützter Workloads

Da auf die sekundären Replikatdatenbanken bei der Wiederherstellung nicht zugegriffen werden kann, tritt bei schreibgeschützten Workloads ein Fehler auf. Aktualisieren Sie die Routingtabelle für die Leseabsicht, um Datenverkehr zurück an das primäre Replikat oder an ein anderes sekundäres Replikat weiterzuleiten, bis die betroffene sekundäre Replikatdatenbank den Wiederherstellungsvorgang abgeschlossen hat.

Vermeiden des Wiederherstellens des Zustands – Überwachen auf große Transaktionen

Wenn Sie diesen Zustand häufig während geplanter Failover beobachten, implementieren Sie eine Prozedur, die vor Failovern auf große Transaktionen überprüft. Die folgende Abfrage meldet den Transaktionsbeginn und die aktuelle Uhrzeit aller geöffneten Transaktionen im System und stellt den Eingabepuffer der Transaktionen bereit.

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC