Problembehandlung für eine Verfügbarkeitsgruppendatenbank beim Wiederherstellen des Zustands

Dieser Artikel hilft Ihnen bei der Problembehandlung einer Verfügbarkeitsgruppendatenbank beim Wiederherstellen des Zustands.

Was ist der Wiederherstellungszustand?

Der Revertierungsstatus tritt auf, 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 verbleiben 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 des Failovers wird dieser verbundene Zustand getrennt. Sobald das neue primäre Replikat online ist, wird die Konnektivität zwischen dem primären Replikat und den sekundären Replikaten wieder hergestellt. Während dieses anfänglichen verbindungsgebundenen Zustands wird ein gemeinsamer Wiederherstellungspunkt ausgehandelt, in dem die neue sekundäre Wiederherstellung gestartet werden soll, damit sie mit dem primären synchronisiert wird.

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

Der Reverting-Prozess ist inhärent langsam, tritt häufig auf, und in der Regel werden kleine Transaktionen, die den Revertierungszustand auslösen, kaum bemerkt. Der Wiederherstellungszustand wird häufig bemerkt, wenn ein Failover eine große Transaktion unterbricht, wodurch viele Seiten von der primären an die sekundäre Replikatdatenbank gesendet werden, um die sekundäre Replikatdatenbank auf einen wiederherstellbaren Zustand zurückgesetzt zu werden.

Symptome und Auswirkungen einer Verfügbarkeitsgruppendatenbank im Wiederherstellen des Zustands

Wenn eine Datenbank den Zustand für das sekundäre Replikat zurückgesetzt hat, wird die Datenbank nicht synchronisiert und empfängt daher keine Änderungen vom primären Replikat. Ein plötzlicher Verlust der Datenbank im primären Replikat kann zu Datenverlust führen.

Always On dashboard reports Not Synchronizeizing on the primary

Nachdem Sie eine Verfügbarkeitsgruppe nicht mehr ausgeführt haben, können Sie feststellen, dass die sekundäre Datei während des Erfolgreichen des Failovers als nicht synchronisiert gemeldet wird. Das Always On-Dashboard meldet , dass die primäre Synchronisierung nicht ausgeführt und auf der sekundären Seite wiederhergestellt wird .

Always On dashboard reports Not Synchronizeizing on the primary	Always On dashboard reports Reverting on the secondary

Always On DMVs reports NOT SYNCHRONIZING on the primary

Wenn Sie die folgenden Always On-Verfügbarkeitsgruppen (AGs) dynamische Verwaltungsansichten (DYNAMIC Management Views, DMVs) für die primäre Abfrage abfragen, befindet sich die Datenbank im Zustand NICHT SYNCHRONISIERT .

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 Abfrage abfragen, befindet sich die Verfügbarkeitsgruppendatenbank im STATUS "REVERTING ".

Schreibgeschützte Arbeitsauslastungen 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 Wiederherstellungszustand befindet, kann es erforderlich sein, diese Arbeitslasten an ein anderes sekundäres Replikat oder das primäre Replikat umzuleiten, wenn diese Workloads geschäftskritisch sind.

Wenn Sie über eine schreibgeschützte Workload verfügen, z. B. eine Berichtsworkload, die an das sekundäre Replikat weitergeleitet wird, schlagen diese Batches möglicherweise mit Nachricht 922 fehl:

Msg 922, Level 14, State 1, Line 2 Database 'agdb' wird wiederhergestellt. Warten Sie, bis die Wiederherstellung beendet ist.

Eine Anwendung, die versucht, sich bei der sekundären Replikatdatenbank beim Wiederherstellen des Zustands anzumelden, kann keine Verbindung herstellen und löst Fehler 18456 aus:

2023-01-26 13:01:13.100 Anmeldefehler: 18456, Schweregrad: 14, Zustand: 38. 2023-01-26 13:01:13.100 Anmeldung für Benutzer '<Benutzername>' fehlgeschlagen. Grund: 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 den Statusstatus alle fünf Minuten zurückgibt.

Stellen Sie eine Verbindung mit dem sekundären Replikat mithilfe von SQL Server Management Studio (SSMS) Objekt-Explorer her, und führen Sie einen Drilldown in Management, Extended Events und dann Sessions durch. Klicken Sie mit der rechten Maustaste auf das AlwaysOn_health Ereignis, und wählen Sie "Livedaten ansehen" aus. Sie sollten ein neues Fenster im Registerkartenformat abrufen, in dem der aktuelle Zustand des Wiederherstellungsvorgangs gemeldet wird. Der Zustand wird alle fünf Minuten über das hadr_trace_message Ereignis gemeldet, und der abgeschlossene Prozentsatz des Wiederherstellungsvorgangs wird gemeldet.

Das SQL Server-Fehlerprotokoll für das sekundäre Replikat ist beim Abschätzen des Abschlusses nicht sehr hilfreich. Aus der folgenden Abbildung können Sie zwischen 10:08 und 11:03 beobachten, während sie den Zustand wiederherstellen, es wird wenig gemeldet. Nachdem die sekundäre Seite alle Seiten des primären Replikats empfangen hat, kann sie jetzt die Transaktion zurücksetzen, die auf dem ursprünglichen Primären ausgeführt wurde, der den Wiederherstellen-Zustand ausgelöst hat. Die Wiederherstellung läuft von 11:03 bis 11:05 Uhr. Kurz nach Abschluss der Wiederherstellung sollte die Datenbank mit dem primären Replikat synchronisiert werden und alle Änderungen, die am primären Computer vorgenommen wurden, aufholen, während die sekundäre Datenbank wieder zurückgesetzt wurde.

Überwachen der Wiederherstellungszeit mithilfe von Leistungsmonitor

Überwachen Sie den Statusstatus mithilfe der Leistungsindikatoren SQL Server:Database Replica:Total Log Requiring Undo and SQL Server:Database Replica:Log Remaining for Undo , and choose the availability group database for the Instance. Im beispiel im folgenden Screenshot wird "Total Log Requiring Undo " als 56,3 mb gemeldet, und "Log Remaining for Undo " wird langsam auf 0 abgelegt, in dem der Fortschritt wiederhergestellt wird.

Was sind andere Optionen als Warten?

Microsoft empfiehlt, die Zeit für den Abschluss des Wiederherstellungszustands 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 hohe Verfügbarkeit und Redundanz bieten und aktiv mit dem primären Replikat synchronisiert werden kann, während die anderen sekundären Replikate wiederhergestellt werden.

Behandeln von fehlerhaften schreibgeschützten Arbeitsauslastungen

Da auf die sekundären Replikatdatenbanken beim Wiederherstellen nicht zugegriffen werden kann, treten schreibgeschützte Workloads fehl. Aktualisieren Sie die Routingtabelle zum Lesen von Absichten, um den Datenverkehr an das primäre Replikat oder an ein anderes sekundäres Replikat weiterzuleiten, bis die betroffene sekundäre Replikatdatenbank den Wiederherstellungsvorgang abgeschlossen hat.

Wiederherstellen des Zustands vermeiden – Monitor für große Transaktionen

Wenn Sie diesen Zustand häufig während geplanter Failovers beobachten, implementieren Sie eine Prozedur, die vor failovers auf große Transaktionen überprüft. Die folgende Abfrage meldet die Transaktionsanfangszeit 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