Warum ein schnelles VPN einen synchronen SQL-Commit noch ausbremst

Öffnen Sie eine Abfragesitzung auf dem Primär und beobachten Sie, worauf ein einfaches Schreiben wartet. Gehört die Datenbank zu einer Verfügbarkeitsgruppe mit synchronem Commit und ist das Sekundär verbunden, verlässt ein Teil dieser Wartezeit das Gebäude: Log-Sätze reisen zum Replikat, werden dort gehärtet, und die Kunde von dieser Härtung kommt zurück, bevor der Commit abgeschlossen ist. Bandbreite verkürzt diesen Hin- und Rückweg nicht. Der folgende Durchlauf verfolgt die Bestätigung vom Bildschirm zur entfernten Platte und wieder zurück.

Beginnen Sie beim Wartetyp auf dem Primär

Ein Schreiben, das auf dem entfernten Replikat wartet, erscheint als logbezogene Wartezeit statt als CPU- oder Sperrwartezeit, und die Dauer der Transaktion folgt dem Hin- und Rückweg statt der Zeilenzahl. Viele kleine Commits machen das deutlich, weil jeder den Weg einzeln bezahlt. Ein einzelner Massenvorgang verbirgt dieselben Kosten in einer längeren Bestätigung.

Sortieren Sie Ihre Arbeitslast nach Commit-Häufigkeit, bevor Sie irgendetwas über die Verbindung schließen.

Lesen Sie den Replikatzustand, bevor Sie das Netzwerk lesen. Die wichtigen Zähler sind die Sendewarteschlange, die Redo-Warteschlange und der Synchronisierungszustand, und zusammen zeigen sie, ob das Sekundär mithält oder zurückfällt. Eine wachsende Sendewarteschlange deutet auf den Transport hin, eine wachsende Redo-Warteschlange dagegen auf die eigene Arbeit oder den Speicher des Sekundärs. Das sind unterschiedliche Reparaturen, und keine davon wird durch mehr Bandbreite besser.

Verfolgen Sie die Bestätigung zum Sekundär

Bei synchronem Commit wartet der Primär auf die Bestätigung, dass das betreffende Log auf dem Sekundär gehärtet wurde, bevor er den Commit als erledigt meldet. Gehärtet bedeutet dauerhaft im Log, nicht in Datenseiten eingespielt. Genau diese Unterscheidung erklärt, warum ein synchrones Sekundär beim Redo zurückliegen kann, während es die Härtung weiterhin bestätigt.

Gehen Sie den Weg der Reihe nach und messen Sie jede Stufe statt des Ganzen. Log-Sätze gehen über den Transport, das Sekundär schreibt und spült sie, und die Bestätigung kehrt auf demselben Weg zurück. Transportverzögerung, Planung des Sekundärs und Latenz der Log-Platte des Sekundärs fließen alle in die Summe ein, und nur die erste gehört dem Netzwerkverantwortlichen. Ein Sekundär, dessen Log-Volumen durch etwas anderes gesättigt ist, kann jeden Commit strecken, während die Verbindung untätig ist.

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

Nehmen Sie diesen Schnappschuss vor und nach einem repräsentativen Schreiben auf, nicht einmal an einem ruhigen Nachmittag. Die Differenz sagt Ihnen, welche Warteschlange sich bewegt hat, während der Commit wartete.

Messen Sie den Weg statt der Verbindung

Ein Durchsatztest misst die Kapazität zwischen zwei Punkten, die nicht Ihre Replikate sind, unter einer Last, die nicht Ihre Arbeitslast ist. Bitten Sie den Netzwerkverantwortlichen um Verzögerung und Verlust entlang des echten Replikatwegs, während echter Verkehr läuft, in beide Richtungen. Verlust wiegt hier schwerer als Kapazität, weil ein verlorenes Segment eine Übertragungswiederholung kostet und jeder Commit auf eine Bestätigung wartet. Eine Verbindung, die in einem Downloadtest hervorragend aussieht, kann für ein gesprächiges Commit-Muster trotzdem ungeeignet sein.

Halten Sie Transportsicherheit und Zugriffskontrollen der Datenbank beim Messen intakt. Einen Weg zu messen ist nie ein Grund, sie zu umgehen.

Korrelieren Sie die Zeiten mit den Zählern statt mit dem Bauchgefühl. Bleibt die Sendewarteschlange leer und der Commit wartet trotzdem, liegt die Verzögerung in der Bestätigung oder im Spülen des Sekundärs. Wächst die Sendewarteschlange stetig, sind Transport oder Kapazität die Einschränkung. Notieren Sie, welche Beobachtung die Schlussfolgerung stützte, damit die nächste Person die Messung wiederholen kann statt die Diskussion.

Was der asynchrone Modus wirklich ändert

Asynchroner Commit entfernt das Warten auf die Härtungsbestätigung des Sekundärs, deshalb werden Schreibvorgänge schneller und deshalb ändert sich Ihre Haltbarkeitsposition. Der Primär bestätigt die Transaktion ohne diese entfernte Bestätigung. Dem Sekundär ist dann Rückstand erlaubt, und dieser Rückstand ist die Exposition.

Geht der Primär verloren, bevor das Log ein nutzbares Failover-Ziel erreicht, verwirft das Erzwingen des Dienstes auf diesem Replikat Transaktionen, von denen der Anwendung bereits mitgeteilt wurde, dass sie committet sind.

Das ist eine Entscheidung zum Wiederherstellungspunkt und gehört dem Datenbankverantwortlichen, nicht einer Leistungsüberprüfung. Legen Sie zuerst das tolerierte Datenverlustfenster fest, wählen Sie den Modus, der es erfüllt, und optimieren Sie dann innerhalb dieser Grenze. Optionen, die den synchronen Schutz erhalten, umfassen das Entfernen vermeidbarer Commit-Hin- und Rückwege, wo die Anwendung es erlaubt, das Beheben eines gemessenen Engpasses bei Transport oder Speicher und das Verschieben des Replikats, damit die Bestätigung weniger Strecke zurücklegt. Wägen Sie sie gegen die Haltbarkeitsanforderung ab, mit der Sie begonnen haben und die sich nicht geändert hat.