Always-On-Replica synchronisiert nicht

Synchronization Health rot, Queues wachsen, die Uhr tickt: Log Send Queue von Redo Queue unterscheiden — und gezielt eingreifen.

Es ist Freitagnachmittag, 16:48 Uhr. Bei der Trendforge Digital GmbH steht für das Wochenende das große Patching an — und beim Routine-Blick ins Always-On-Dashboard wird dem DBA flau: Die Synchronization Health der DR-Replica steht auf Rot, und zwar offenbar nicht erst seit heute. Die Log Send Queue der Hauptdatenbank: 94 GB und wachsend. Übersetzt heißt das: Fällt der Hauptstandort jetzt aus, fehlen auf der DR-Seite die letzten eineinhalb Tage — und ganz nebenbei meldet das Monitoring, dass das Transaktionslog des Primary seit gestern nicht mehr abgeschnitten wird und das Log-Laufwerk sich bedrohlich füllt. Aus einem stillen Sync-Problem sind in 36 Stunden zwei Notfälle geworden.

Willkommen beim Symptom mit der eingebauten tickenden Uhr. Eine hängende Always-On-Synchronisierung tut im Tagesgeschäft erst einmal niemandem weh — die Anwender merken nichts, der Primary läuft. Aber im Hintergrund wächst mit jeder Minute die Datenverlust-Exposition, und das Transaktionslog des Primary kann nicht mehr aufräumen. Dieser Beitrag aus dem SQL-Server-Notarztwagen (die Triage-Übersicht liegt unter /sql-server-notarztwagen/) zeigt dir, wie du mit den beiden Queues die Diagnose in zwei Lager trennst — Transport oder Verarbeitung —, die häufigsten Ursachen abräumst und die Uhr anhältst, bevor aus dem Sync-Problem ein LOG_FULL wird.

Was bedeutet das technisch?

Der Datenfluss einer Availability Group ist eine Pipeline mit zwei möglichen Stau-Punkten. Auf dem Primary wird jede Transaktion ins lokale Log gehärtet; die Log-Blöcke wandern dann in die Log Send Queue und werden über den Mirroring-Endpoint (Standard-Port 5022) an die Secondaries gesendet. Dort werden sie empfangen, ins lokale Log gehärtet — im synchronen Modus geht erst jetzt das ACK zurück, auf das der Commit des Primary wartet — und landen in der Redo Queue, aus der der Redo-Thread sie in die Datenbankdateien einspielt. Zwei Queues, zwei völlig verschiedene Krankheitsbilder.

Eine wachsende Log Send Queue ist ein Transport-Problem: Das Log verlässt den Primary nicht schnell genug — weil das Netzwerk zur DR-Site zu schmal oder gestört ist, der Endpoint nicht erreichbar ist, der Secondary nicht annimmt, oder weil schlicht mehr Log produziert wird, als die Leitung je tragen sollte (Stichwort Index-Rebuild-Nacht). Im asynchronen Modus ist diese Queue gleichzeitig deine Datenverlust-Exposition: Was drinsteht, wäre bei einem Primary-Ausfall jetzt weg. Eine wachsende Redo Queue bei leerer Send Queue ist dagegen ein Verarbeitungs-Problem auf dem Secondary: Die Daten sind sicher angekommen — es droht kein Verlust —, aber der Failover würde dauern, denn die komplette Queue muss vor dem Online-Gehen abgearbeitet werden. Send Queue kostet RPO, Redo Queue kostet RTO: Diese Eselsbrücke trennt neunzig Prozent aller Fälle.

Und dann ist da die tickende Uhr, die dieses GELB-Symptom so heimtückisch macht: Der Primary darf sein Transaktionslog erst abschneiden, wenn alle Replicas die Log-Blöcke erhalten haben. Hängt ein Replica, zeigt log_reuse_wait_desc den Wert AVAILABILITY_REPLICA — und das Log wächst unaufhaltsam, völlig egal, wie fleißig deine Log-Sicherungen laufen. Aus dem Sync-Problem von Mittwoch wird so das LOG_FULL von Freitag; die Lead-Szene ist keine Übertreibung, sondern der Normalverlauf eines unbemerkten Sync-Ausfalls.

Der Diagnose-Pfad: die Pipeline und ihre Stau-Punkte

Die folgende Skizze zeigt den Datenfluss mit beiden Stau-Punkten — und in der roten Box die Uhr, die bei jedem Sync-Problem mitläuft:

Erste Diagnose: konkrete Skripte

Schritt 1 — Das Cockpit: Zustand, Queues und RPO-Lücke

Diese Abfrage — auf dem Primary ausgeführt, weil nur der alle Replicas sieht — liefert die komplette Lagebeurteilung in einem Resultset:

Die Lesart folgt der Skizze: SendQueueMB groß und wachsend — Transport-Lager, weiter zu Ursache eins und zwei. RedoQueueMB groß bei kleiner Send Queue — Verarbeitungs-Lager, weiter zu Ursache drei. is_suspended = 1 — die Bewegung wurde angehalten, suspend_reason_desc verrät warum (weiter zu Ursache vier). Und die Differenz der last_commit_time zwischen Primary und Secondary ist deine aktuelle RPO-Lücke in Klartext — die Zahl, die in der Lead-Szene „eineinhalb Tage“ hieß und die du der Geschäftsführung nennen können musst. Aus Send Queue und Send Rate ergibt sich außerdem die ehrliche Aufhol-Prognose: 94 GB Queue bei 10 MB/s Rate heißt knapp drei Stunden — wenn nichts Neues dazukommt.

Schritt 2 — Die tickende Uhr prüfen

Schritt 3 — Endpoint und Verbindung testen

Die häufigsten Ursachen — und was du dagegen tust

1. Die Leitung zur DR-Site ist zu schmal — oder gerade verstopft

Der Dauerfall bei asynchronen Replicas am Zweitstandort: Die WAN-Strecke trägt im Normalbetrieb locker, aber bei Lastspitzen — Monatsabschluss, Massenimport — produziert der Primary mehr Log pro Sekunde, als die Leitung schafft, und die Send Queue wächst. Die Diagnose liefert der Vergleich von log_send_rate mit der Log-Erzeugungsrate: Liegt die Send Rate dauerhaft an der Leitungsgrenze, ist die Strecke das Limit. Kurzfristig hilft nur warten und die Aufhol-Prognose kommunizieren; mittelfristig sind die Hebel Leitungs-Upgrade, Kompression der Endpoint-Verbindung prüfen — und vor allem die Log-Erzeugung glätten, was direkt zu Ursache fünf führt.

2. Der Endpoint streikt — Firewall, Berechtigung, Zertifikat

Wenn die Send Queue wächst und die Send Rate bei null liegt, ist die Verbindung tot, nicht langsam. Die üblichen Verdächtigen in absteigender Häufigkeit: eine Firewall-Änderung, die Port 5022 zwischen den Standorten kappt (gern nach Netzwerk-Wartungen, von denen der DBA nichts wusste); fehlende CONNECT-Berechtigung des Service-Accounts auf dem Gegenüber-Endpoint — klassisch nach einem Wechsel des Dienstkontos; abgelaufene Zertifikate bei zertifikatbasierter Endpoint-Authentifizierung; und Kerberos-Verwandtschaft (SPNs!), die du aus dem Login-Beitrag des Notarztwagens kennst. Das ERRORLOG mit Error 35202 und die Test-NetConnection-Probe trennen die Fälle: Kommt TCP durch, ist es Authentifizierung; kommt es nicht durch, ist es Netz.

3. Redo hängt — das Readable Secondary blockiert sich selbst

Das Verarbeitungs-Lager: Send Queue leer, Redo Queue wächst. Häufigster Täter ist das Readable Secondary selbst: Lang laufende Abfragen auf dem lesbaren Replica können den Redo-Thread blockieren — besonders brutal, wenn vom Primary DDL hereinkommt (ein Index-Rebuild, eine Schemaänderung), das eine Sperre braucht, die der Vier-Stunden-Report gerade hält. Der Redo steht dann komplett, bis der Report fertig ist oder gekillt wird. Diagnose: Blocking-Analyse auf dem Secondary (das Ketten-Skript aus dem Blocking-Beitrag funktioniert dort genauso). Therapie: Reporting-Fenster und Wartungsfenster entkoppeln, notorische Langläufer auf dem Secondary überwachen — und akzeptieren, dass „lesbar“ nicht „folgenlos“ heißt. Zweiter Verdächtiger bei chronisch zäher Redo Rate: schlicht langsameres Storage am Secondary — die DR-Maschine ist eben doch nicht „fast gleich“ ausgestattet.

4. Die Datenbank ist suspendiert — und keiner hat es gemerkt

Steht is_suspended = 1, hat entweder jemand die Datenbewegung manuell angehalten (SUSPEND_FROM_USER — der Kollege, der „nur kurz was testen“ wollte) oder SQL Server selbst hat nach einem Fehler die Reißleine gezogen: Platte am Secondary voll, I/O-Fehler, Log-Probleme. Der suspend_reason_desc aus dem Cockpit-Skript nennt den Grund. Die Therapie ist zweistufig und die Reihenfolge ist Pflicht: erst die Ursache beheben (Platz schaffen, Storage-Fehler klären), dann die Bewegung wieder anwerfen mit ALTER DATABASE [DB] SET HADR RESUME — auf dem betroffenen Secondary ausgeführt. Wer resumed, ohne die Ursache zu beheben, sieht die Suspendierung in Minuten wieder.

5. Die Log-Flut der Wartungsnacht — selbstgemachter Stau

Der unterschätzte Klassiker: Sonntagnacht laufen die Index-Rebuilds, und ein Rebuild erzeugt Log in Tabellengröße — die komplette Neuschreibung wandert durch die Pipeline zu jedem Replica. Eine Wartungsnacht kann so mühelos hunderte GB Log produzieren und die DR-Strecke für Stunden in den Rückstand zwingen; Montagmorgen ist die Synchronisierung dann „plötzlich“ rot. Therapie: die Wartung log-schonend planen — Rebuilds nur, wo nötig (Stichwort Schwellenwerte aus dem Index-Wartungs-Beitrag), auf Enterprise resumable Online-Rebuilds in Etappen, große Operationen über mehrere Nächte verteilen — und die Send Queue während der Wartung überwachen statt erst danach. Wer seine DR-Leitung kennt, plant die Wartung um sie herum, nicht gegen sie.

Was du auf keinen Fall tun solltest

Nachsorge: Damit es nicht wiederkommt

Drei strukturelle Maßnahmen nach dem akuten Fall: Erstens, Queue-Monitoring mit Alarmen — Send Queue, Redo Queue und die last_commit_time-Differenz gehören mit Schwellenwerten ins Monitoring, damit ein hängendes Replica nach Minuten auffällt statt nach 36 Stunden. Die eingebaute AlwaysOn_health-XE-Session läuft bereits und liefert die Ereignis-Historie für jede Nachschau. Zweitens, die Wartung mit der DR-Leitung versöhnen: Log-Erzeugung der Wartungsnächte messen, Rebuilds selektiv und gedrosselt fahren, große Läufe verteilen — die Send Queue der Sonntagnacht ist planbar. Drittens, regelmäßige Failover-Tests: Eine Synchronisierung, deren Schwenk nie geprobt wurde, ist genauso viel wert wie ein Backup ohne Restore-Test — wie man das gefahrlos und mit Messwerten tut, zeigt der DR-Test-Beitrag der GRÜN-Stufe.

Vertiefung in der Buchreihe

Always-On-Architektur, Quorum-Fragen und Failover-Strategien füllen in der Buchreihe „SQL Server in der Praxis“ einen ganzen Band — alle Bände in der Übersicht auf der SQL-Pillar-Seite unter /sql-server/.

Verwandte Notfälle im Notarztwagen

Sync-Probleme haben direkte Folge-Notfälle — diese Beiträge aus dem Cluster lohnen den Blick:

Drei Wege, wenn das Replica jetzt gerade hinterherhinkt

Festpreis-Analyse

Die Synchronisierung kippt immer wieder, niemand weiß, ob die DR-Seite im Ernstfall trägt, und das letzte Failover-Protokoll ist von der Einrichtung? Dafür gibt es die Festpreis-Analyse: Ich prüfe Topologie und Commit-Modi, werte Queue-Verläufe und die AlwaysOn_health-Historie aus, kontrolliere Endpoints, Berechtigungen und die Wartungs-Log-Last und liefere einen Bericht mit priorisierten Maßnahmen — inklusive einer ehrlichen RPO/RTO-Aussage für die Geschäftsführung. Zum vereinbarten Festpreis, ohne Stundenzähler.

Akut-Hotline

Wenn die Send Queue gerade jetzt zweistellige GB-Werte zeigt und das Log-Laufwerk eng wird: anrufen. Halte die Ausgabe des Cockpit-Skripts bereit (oder einen Zugang mit VIEW-SERVER-STATE-Rechten) und die Antwort auf die Schlüsselfrage — was lief zuletzt: Wartungsnacht, Netzwerk-Änderung, Konten-Wechsel? Mit den beiden Queues ist das Lager in Minuten bestimmt, und für die Log-Uhr gibt es fast immer eine Sofortmaßnahme.

Selbst-Diagnose-Kit

Du willst die AG-Diagnose selbst im Griff haben? Das Diagnose-Kit bündelt die Skripte aus diesem Beitrag — Sync-Cockpit mit RPO-Berechnung, Log-Uhr-Check, Endpoint-Prüfung, Redo-Blocker-Analyse — als ausführbares Paket mit Auswertungshilfe und einer Eskalations-Checkliste vom ersten Alarm bis zur Failover-Entscheidung.

Häufige Fragen (FAQ)

Diese Sektion ist auf häufige Suchanfragen abgestimmt. Sie hilft dir, schnell den Punkt zu finden, der dir gerade akut weiterhilft — und sie ist gleichzeitig die Eingabe für das FAQPage-Schema auf der Seite.

Warum synchronisiert mein Always-On-Replica nicht?

Die Antwort steckt fast immer in einer von zwei Queues: Wächst die Log Send Queue auf dem Primary, kommt das Log nicht zum Secondary — ein Transport-Problem (Netzwerk, Endpoint, Secondary nimmt nicht an) oder schlicht eine Log-Flut, die schneller wächst, als die Leitung trägt. Wächst dagegen die Redo Queue auf dem Secondary, kommt das Log zwar an, wird aber nicht schnell genug eingespielt — typisch, wenn Abfragen auf einem Readable Secondary den Redo-Thread blockieren oder das Storage dort lahmt. Die Abfrage über sys.dm_hadr_database_replica_states in diesem Beitrag trennt die beiden Fälle in einer Minute.

Was ist die Log Send Queue?

Die Log Send Queue ist die Menge an Transaktionslog auf dem Primary, die bereits gehärtet, aber noch nicht an ein Secondary gesendet wurde — gemessen in KB pro Replica und Datenbank. Sie ist die wichtigste Kennzahl im asynchronen Modus, denn sie ist nichts anderes als deine aktuelle Datenverlust-Exposition: Fällt der Primary jetzt aus, ist alles in dieser Queue weg. Eine wachsende Send Queue heißt, dass der Transport nicht hinterherkommt — wegen Netz, Endpoint oder weil gerade eine Wartung (Index-Rebuilds!) mehr Log produziert, als die Leitung zur DR-Site schafft.

Was ist die Redo Queue?

Die Redo Queue ist die Menge an Log, die auf dem Secondary bereits empfangen und gehärtet, aber noch nicht in die Datenbankdateien eingespielt (redone) wurde. Sie kostet keinen Datenschutz — die Daten sind ja sicher angekommen —, aber sie kostet Failover-Zeit: Bei einem Schwenk muss die komplette Redo Queue erst abgearbeitet werden, bevor die Datenbank auf dem neuen Primary online geht. Eine wachsende Redo Queue bei leerer Send Queue heißt: Das Problem liegt auf dem Secondary — meist blockieren Abfragen auf einem Readable Secondary den Redo-Thread, oder das dortige Storage ist zu langsam.

Wie nutze ich sys.dm_hadr_database_replica_states?

Die DMV ist das Cockpit der Synchronisierung: pro Datenbank und Replica liefert sie synchronization_state_desc (SYNCHRONIZED, SYNCHRONIZING, NOT SYNCHRONIZING), synchronization_health_desc, die log_send_queue_size und redo_queue_size in KB, die zugehörigen Raten (log_send_rate, redo_rate) sowie last_commit_time — aus deren Differenz zwischen Primary und Secondary du deine aktuelle RPO-Lücke abliest. Am aussagekräftigsten ist die Abfrage auf dem Primary, weil der die Sicht auf alle Replicas hat. Das fertige Skript mit allen relevanten Spalten und der Interpretation steht im Diagnose-Abschnitt dieses Beitrags.

Wie teste ich die Endpoint-Verbindung?

In drei Stufen. Erstens die Konfiguration: SELECT name, state_desc, port FROM sys.tcp_endpoints zeigt, ob der Mirroring-Endpoint (Standard-Port 5022) überhaupt STARTED ist. Zweitens die Erreichbarkeit: Von jedem Replica aus per Test-NetConnection auf Port 5022 der anderen Knoten prüfen — Firewalls zwischen Standorten sind der Klassiker. Drittens die Authentifizierung: Im ERRORLOG nach Error 35202 oder „Connection timeout“ suchen; bei Domänen-Konten muss der Service-Account jedes Replicas CONNECT-Berechtigung auf den Endpoints der anderen haben, bei zertifikatbasierter Authentifizierung dürfen die Zertifikate nicht abgelaufen sein. Details im Endpoint-Abschnitt.

Was tun, wenn die Synchronization Health rot ist?

Erst Befund, dann Eingriff: Mit der Replica-States-Abfrage klären, welche Datenbank auf welchem Replica in welchem Zustand hängt — und ob die Send Queue oder die Redo Queue wächst. Steht der Zustand auf NOT SYNCHRONIZING, prüfe zusätzlich, ob die Datenbank suspendiert wurde (is_suspended samt suspend_reason): Nach Fehlern hält SQL Server die Bewegung an, und nach behobener Ursache bringt ALTER DATABASE … SET HADR RESUME den Datenfluss zurück. Parallel die tickende Uhr im Blick behalten: Solange ein Replica hängt, kann der Primary sein Log nicht abschneiden — das Transaktionslog wächst, bis die Synchronisierung wieder läuft.

Wie führe ich einen manuellen Failover durch?

Der saubere Weg ist der geplante Failover ohne Datenverlust: Er setzt voraus, dass das Ziel-Replica im synchronen Commit-Modus läuft und SYNCHRONIZED ist — dann genügt ALTER AVAILABILITY GROUP [AG] FAILOVER auf dem Ziel (oder der Assistent in SSMS), und die Rollen tauschen verlustfrei. Aus einem asynchronen oder nicht synchronisierten Zustand gibt es nur den erzwungenen Failover mit FORCE_FAILOVER_ALLOW_DATA_LOSS — und der heißt so, weil er genau das bedeutet: Alles in der Send Queue ist verloren. Der erzwungene Weg ist eine Katastrophen-Entscheidung mit Management-Freigabe, kein Ungeduld-Werkzeug. Wie man Failover gefahrlos übt, zeigt der DR-Test-Beitrag.