Warum Ihr synchroner SQL-Commit auf die VPN-Runde wartet

Die Schreiblatenz schnellte hoch, nachdem ein Replik an den zweiten Standort umzog, und der Tunnel ist die neueste Komponente, also bekommt er die Schuld. Der Tunnel kann unschuldig sein: Innerhalb einer Verfügbarkeitsgruppe mit synchronem Commit kann das primäre Replik einen Commit erst bestätigen, wenn ein entfernter Logschreibvorgang abgeschlossen ist, sodass jede Transaktion einen Roundtrip bezahlt, egal wie viele Megabit die Verbindung trägt. Durchsatz misst Bytes pro Sekunde, Latenz misst, wie lange ein Austausch dauert, und ein Commit braucht nur einen kleinen Austausch, um fertig zu werden. Eine Zahl entscheidet die Debatte: die Commit-Dauer einer kleinen Transaktion, gemessen in der Verfügbarkeitsdatenbank und erneut gegen eine lokale Tabelle auf derselben Instanz.

Worauf das primäre Replik tatsächlich wartet

Bei synchronem Commit hält das primäre Replik die Commit-Bestätigung zurück, bis der Partner bestätigt, dass seine Logeinträge gehärtet sind. Gehärtet bedeutet dauerhaft in das Transaktionslog des sekundären Repliks geschrieben, nicht in dessen Datenseiten nachgespielt. Redo kann Minuten hinterherhinken, ohne dem Commit des primären Repliks eine Millisekunde hinzuzufügen.

Microsofts Dokumentation zu den Verfügbarkeitsmodi beschreibt diesen Handshake und was die Plattform tut, wenn ein Partner ausfällt. Ein als synchron markiertes Replik ist eine Regel über das Warten, kein dauerhaftes Versprechen, dass für jeden Commit eine gesunde entfernte Kopie existiert. Der getrennte Pfad ist separat definiert, und er bedeutet nicht einfach, dass der Commit fehlschlägt.

Die beobachtete Wartezeit ist also eine Summe: Logtransport, Scheduling auf beiden Hosts und der Schreibvorgang auf den entfernten Speicher. Ein sekundäres Replik mit gesättigtem Logvolumen fügt Zeit hinzu, die kein Geschwindigkeitstest zeigt. Diese Platte wird selten gemessen, wenn die Beschwerde den VPN nennt.

Bandbreite ist keine Roundtrip-Verzögerung

Ein Geschwindigkeitstest flutet den Pfad kurz und meldet eine Rate. Ein Commit fragt etwas Engeres: wie lange eine kleine Nachricht braucht, um die Gegenseite zu erreichen, persistiert zu werden und zurückzukommen. Pfadlänge, Warteschlangen und Paketverlust bestimmen diese Zahl, und nichts davon verbessert sich, wenn der Anbieter die Obergrenze anhebt.

Ein „schneller“ Tunnel kann einer schreiblastigen Arbeitslast aus vielen kleinen sequenziellen Transaktionen daher eine sichtbare Strafe hinzufügen. Dieselbe Byte-Summe auf tausend Commits verteilt zahlt den Roundtrip tausendmal; eine Massenübertragung zahlt ihn einmal.

Bitten Sie den Netzwerkeigentümer um Verzögerung und Verlust, gemessen über die Replikaroute selbst unter repräsentativer Last. Ein Ping von einem Bürolaptop zum VPN-Gateway oder ein Geschwindigkeitstest zu einem nahen Knoten schreibt der Route, die das Log tatsächlich nimmt, fast nichts zu. Sorgen Sie dafür, dass das Messfenster die Stunden überlappt, in denen Schreiben langsam ist.

Lesen Sie den Replikastatus, bevor Sie etwas ändern

Beginnen Sie mit dem, was die Instanzen über sich selbst berichten, denn die beiden Seiten können uneinig darüber sein, wie gesund die Partnerschaft ist, und ein Dashboard-Durchschnitt verbirgt, welche Warteschlange sich bewegt. Die Abfragen unten beantworten unterschiedliche Fragen: eine liest den Replikationsstatus pro Datenbank, die andere liest, wie jedes Replik konfiguriert ist. Führen Sie beide aus, bevor Sie einen Modus anfassen.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;

Das erste Ergebnis trennt Logtransport von Redo. log_send_queue_size steigt, während redo_queue_size flach bleibt, bedeutet, dass das Log nicht angekommen ist; das Gegenteil bedeutet, dass es angekommen ist und das Nachspielen hinterherhinkt. Nur der erste Fall liegt auf dem Commit-Pfad.

Das zweite Ergebnis bestätigt, welche Replikate wirklich so konfiguriert sind, wie Sie annehmen, denn ein während eines früheren Vorfalls geänderter Modus bleibt meist geändert und undokumentiert. Lesen Sie die Zeile, die Sie interessiert, statt der Gruppenvorgabe: availability_mode_desc und failover_mode_desc gelten pro Replik. secondary_lag_seconds gibt es nur ab SQL Server 2016, sodass ein älterer Build Ihnen nur die Spalten für Sendewarteschlange und Redo lässt.

Messen Sie dann ein repräsentatives Schreiben, statt einem Dashboard-Durchschnitt zu vertrauen. Führen Sie den Block unten in der Verfügbarkeitsdatenbank aus und dann erneut gegen dieselbe Tabellenform in einer Datenbank außerhalb der Gruppe auf derselben Instanz. Die Lücke zwischen den beiden Dauern ist ein grober Preis für das entfernte Log, und sie hält in einer Diskussion mit dem Netzwerkteam deutlich besser stand als eine Grafik. Ändern Sie danach jeweils eine Variable, sonst bedeutet die Lücke nichts mehr.

IF OBJECT_ID('dbo.CommitProbe') IS NULL
    CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
    INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;

Was asynchroner Commit kauft und was er kostet

Bei asynchronem Commit hört das primäre Replik auf, auf die Bestätigung der entfernten Härtung zu warten, sodass der Roundtrip den Commit-Pfad verlässt. Die Commit-Latenz sinkt und das sekundäre Replik darf hinterherhinken, um ein Maß, das niemand kontrolliert. Das ist eine echte Lösung für die Wartezeit und eine echte Änderung des Versprechens.

Der Preis ist eine Entscheidung über den Wiederherstellungspunkt. Wenn das primäre Replik stirbt, bevor sein Log ein Failover-Ziel erreicht, das Sie tatsächlich nutzen können, verwirft das Verschieben des Dienstes auf die asynchrone Kopie Transaktionen, die die Anwendung bereits als committet gemeldet hat. Kein Konfigurationsdialog stellt es so dar, denn es ist eine Geschäftsfrage über akzeptablen Verlust, keine Leistungseinstellung. Schreiben Sie das tolerierte Verlustfenster vor dem Vorfall auf, nicht währenddessen.

Vereinbaren Sie den Modus mit dem Eigentümer der Daten schriftlich, zusammen mit dem Failover-Verfahren für den Fall, dass das bevorzugte Ziel nicht verfügbar ist. Synchron in einem Designdokument ist kein Betriebshandbuch, und asynchron ist keine Lizenz, die Warteschlangen nicht mehr zu beobachten.

Wählen Sie eine Lösung, die Sie hinterher verteidigen können

Es gibt vier ehrliche Optionen. Schneiden Sie vermeidbare Commit-Roundtrips weg, wo die Semantik der Anwendung Batching erlaubt; beheben Sie einen gemessenen Transport- oder Speicherengpass, was ein schnelleres Logvolumen auf dem sekundären Replik statt einer größeren Leitung bedeuten kann; rücken Sie das Replik näher heran, damit der Roundtrip schrumpft; oder lockern Sie die Schutzrichtlinie und akzeptieren Sie ein breiteres Verlustfenster. Jede kauft Latenz, indem sie etwas anderes ausgibt, und die vierte gibt Haltbarkeit aus. Benennen Sie die Ausgabe, bevor Sie wählen.

Entscheiden Sie mit dem Latenzziel der Arbeitslast und ihrer Haltbarkeitsanforderung gleichzeitig vor Augen, denn die Optimierung des einen verbraucht still das andere. Führen Sie dann dieselbe Transaktion erneut aus, die Sie vor der Änderung gemessen haben. Eine Lösung, die diese Zahl nicht bewegen kann, ist eine Vermutung mit einem Änderungsticket.

Halten Sie die Vorher-und-nachher-Messwerte im Änderungsdatensatz fest. Sonst wiederholt die nächste Person, die langsame Schreibvorgänge sieht, die Untersuchung von Anfang an und beginnt wieder, den Tunnel zu beschuldigen.