Bestimmen, warum Änderungen an primären Replikaten nicht in sekundären Replikat einer Always On-Verfügbarkeitsgruppe angezeigt werden

Gilt für:SQL Server

Die Clientanwendung führt erfolgreich ein Update für das primäre Replikat durch, wobei jedoch die Abfrage des sekundären Replikats ergibt, dass die Änderung nicht widergespiegelt wird. In diesem Fall wird davon ausgegangen, dass Ihre Verfügbarkeit einen intakten Synchronisierungszustand aufweist. In den meisten Fällen löst sich dieses Problem nach einigen Minuten von selbst.

Wenn sich die Änderungen jedoch auch nach wenigen Minuten nicht im sekundäre Replikat widerspiegeln, liegt möglicherweise ein Engpass in der Synchronisierungsworkflow vor. Der Ort des Engpasses hängt davon ab, ob das sekundäre Replikat für synchronen oder asynchronen Commit konfiguriert ist.

Synchroner Commit

Jedes erfolgreiche Update auf dem primären Replikat wurde entweder bereits mit dem sekundären Replikat synchronisiert, oder die Protokolldatensätze wurden auf dem sekundären Replikat bereits zur dauerhaften Speicherung geschrieben. Daher sollte der Engpass im Redo-Prozess liegen, der stattfindet, nachdem das Protokoll auf das sekundäre Replikat geschrieben wurde.

Sobald das Redo jedoch abgeschlossen ist, erfolgen alle Lese-Workloads auf dem sekundären Replikat unter Snapshotisolation:

  • Lang andauernde Transaktionen auf dem primären Replikat

  • Wiederholen auf dem sekundären Replikat

Asynchroner Commit

Da der asynchrone Commit eine Transaktion quittiert, sobald diese auf den lokalen Datenträger geschrieben wurde, kann der Engpass irgendwo nach diesem Punkt liegen:

  • Lang andauernde Transaktionen auf dem primären Replikat

  • Netzwerklatenz oder -durchsatz

  • Protokollfestschreibung auf dem sekundären Replikat

  • Wiederholen auf dem sekundären Replikat

In den folgenden Abschnitten werden die häufigsten Ursachen für das Problem beschrieben, dass sich Änderungen am primären Replikat bei schreibgeschützten Abfragen nicht im sekundären Replikat widerspiegeln.

Lang andauernde aktive Transaktionen

Eine lang andauernde Transaktion auf dem primären Replikat verhindert, dass die Updates für das sekundäre Replikat gelesen werden.

Erklärung

Alle Leseworkloads auf dem sekundären Replikat stellen Momentaufnahme-Isolationsabfragen dar. Bei der Snapshotisolation sehen schreibgeschützte Clients die Verfügbarkeitsdatenbank auf dem sekundären Replikat so, wie sie sich zum Beginn der ältesten aktiven Transaktion im Redo-Protokoll darstellt. Wenn eine Transaktion seit Stunden nicht committet wurde, verhindert die offene Transaktion, dass alle Nur-Lese-Abfragen neue Aktualisierungen sehen.

Diagnose und Lösung

Verwenden Sie auf dem primären Replikat DBCC OPENTRAN (Transact-SQL), um die ältesten aktiven Transaktionen anzuzeigen und herauszufinden, ob ein Rollback für diese ausgeführt werden kann. Sobald ein Rollback für die ältesten aktiven Transaktionen und eine Synchronisierung mit dem sekundären Replikat ausgeführt wurde, können Leseworkloads auf dem sekundären Replikat Updates in der Verfügbarkeitsdatenbank bis zum Anfang der zum jeweiligen Zeitpunkt ältesten aktiven Transaktion sehen.

Eine hohe Netzwerklatenz oder ein niedriger Netzwerkdurchsatz führt zur Protokollanhäufung beim primären Replikat.

Eine hohe Netzwerklatenz oder ein niedriger Durchsatz kann dazu führen, dass Protokolle nicht schnell genug an das sekundäre Replikat gesendet werden.

Erklärung

Das primäre Replikat aktiviert die Flusssteuerung für die Protokollsendung, wenn es die maximal zulässige Anzahl von unbestätigten Nachrichten, die über das sekundäre Replikat gesendet werden, überschritten hat. Erst, wenn einige dieser Nachrichten bestätigt wurden, können weitere Protokollblöcke an das sekundäre Replikat gesendet werden. Diese Situation kann schwerwiegendere Auswirkungen hinsichtlich des möglichen Datenverlusts zur Folge haben, wodurch möglicherweise Ihre Recovery Point Objective (RPO) beeinträchtigt wird.

Diagnose und Lösung

Ein hoher DMV-Wert log_send_queue_size kann darauf hinweisen, dass Protokolle auf dem primären Replikat zurückgehalten werden. Durch Dividieren dieses Werts mit log_send_rate können Sie einen ungefähren Schätzwert erhalten, wie schnell Daten auf dem sekundären Replikat nachgeholt werden können.

Zudem ist es hilfreich, die zwei Leistungsobjekte SQL Server: Verfügbarkeitsreplikat > Flusssteuerungsdauer (ms/s) und SQL Server: Verfügbarkeitsreplikat > Flusssteuerung/s zu überprüfen. Durch Multiplikation dieser zwei Werte erhalten Sie einen bis auf die Sekunde genauen Wert der Wartezeit für die Verarbeitung der Flusssteuerung. Je länger die Wartezeit der Flusssteuerung, desto niedriger ist die Senderate.

Nachfolgend finden Sie eine Liste mit nützlichen Metriken für die Diagnose von Netzwerklatenz und -durchsatz. Sie können andere Windows-Tools wie ping.exe verwenden, um die Netzwerkauslastung auszuwerten.

  • DMV log_send_queue_size

  • DMV log_send_rate

  • Leistungsindikator SQL Server:Database > Log Bytes Flushed/sec

  • Leistungsindikator SQL Server:Database Mirroring > Send/Receive Ack Time

  • Leistungsindikator SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Leistungsindikator SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Leistungsindikator SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Leistungsindikator SQL Server:Availability Replica > Flow Control/sec

  • Leistungsindikator SQL Server:Availability Replica > Resent Messages/sec

Versuchen Sie zur Behandlung dieses Problems, ein Upgrade für Ihre Netzwerkbandbreite durchzuführen oder unnötigen Netzwerkdatenverkehr zu beseitigen oder zu verringern.

Eine andere Reporting-Workload hindert den Redo-Thread daran, ausgeführt zu werden.

Der Redo-Thread auf dem sekundären Replikat wird durch eine lange laufende schreibgeschützte Abfrage daran gehindert, DDL-Änderungen vorzunehmen. Der Redo-Thread muss entsperrt werden, bevor er weitere Updates für die Lese-Workload verfügbar machen kann.

Erklärung

Auf dem sekundären Replikat rufen die schreibgeschützten Abfragen Schemastabilitätssperren (Sch-S) ab. Diese Sch-S-Sperren können den Redo-Thread daran hindern, Schemaänderungs-Sch-M-Sperren zu erwerben, um irgendwelche DDL-Änderungen vorzunehmen. Ein blockierter Redo-Thread kann Logeinträge erst anwenden, bis die Blockierung aufgehoben ist.

Diagnose und Lösung

Wenn der Wiederholungsthread blockiert wurde, wird ein erweitertes Ereignis namens sqlserver.lock_redo_blocked generiert. Darüber hinaus können Sie die DMV „sys.dm_exec_request“ für das sekundäre Replikat abfragen, um herauszufinden, welche Sitzung den REDO-Thread blockiert, und dann entsprechende Korrekturmaßnahmen treffen. Die folgende Abfrage liefert die Sitzungs-ID der Reportingworkload zurück, die den Redo-Thread blockiert.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

Sie können die Berichtsworkload beenden lassen, wodurch die Blockierung des Wiederholungsthreads aufgehoben wird, oder Sie können die Blockierung des Wiederholungsthreads sofort aufheben, indem Sie den Befehl KILL (Transact-SQL) für die blockierende Sitzungs-ID ausführen.

Redo-Thread hinkt aufgrund von Ressourcenkonkurrenz hinterher.

Eine hohe Berichtslast auf dem sekundären Replikat hat die Leistung des sekundären Replikats beeinträchtigt, und der Redo-Thread ist zurückgefallen.

Erklärung

Bei der Anwendung von Protokolldatensätzen auf das sekundäre Replikat liest der Wiederholungsthread die Protokolldatensätze vom Protokolldatenträger und greift dann für jeden Protokolldatensatz auf die Datenseiten zu, um den Protokolldatensatz anzuwenden. Der Seitenzugriff kann E/A-gebunden sein (beim Zugriff auf den physischen Datenträger), wenn sich die Seite noch nicht im Pufferpool befindet. Wenn eine E/A-gebundene meldende Workload vorhanden ist, konkurriert die meldende Workload mit dem Wiederholungsthread um E/A-Ressourcen und kann den Wiederholungsthread verlangsamen. Diese Situation beeinträchtigt nicht nur andere Berichtsworkloads beim Anzeigen aktualisierter Daten, sondern wirkt sich auch auf die RTO aus.

Diagnose und Lösung

Anhand der folgenden DMV-Abfrage können Sie erkennen, wie weit der Wiederholungsthread im Rückstand liegt, indem Sie die Diskrepanz zwischen last_redone_lsn und last_received_lsn messen.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states

Wenn der Redo-Thread tatsächlich hinterherhinkt, müssen Sie die Grundursache für den Leistungsabfall beim sekundären Replikat untersuchen. Falls ein E/A-Konflikt bei der meldenden Workload besteht, können Sie mithilfe des Resource Governor bis zu einem gewissen Grad die von der meldenden Workload verwendeten CPU-Zyklen und so indirekt die durchgeführten E/A-Zyklen steuern. Wenn beispielsweise Ihre Berichtsworkload 10 Prozent der CPU verbraucht, die Workload jedoch E/A-gebunden ist, können Sie Resource Governor verwenden, um die CPU-Ressourcennutzung auf 5 Prozent zu begrenzen und so die Lese-Workload zu drosseln, wodurch die Auswirkungen auf die E/A minimiert werden.

Verwandte Inhalte

  • Last updated on