Hvorfor din synkrone SQL-commit venter på VPN-rundturen

Skrive-latensen sprang i vejret, efter at en replika flyttede til det andet site, og tunnelen er den nyeste komponent, så den får skylden. Tunnelen kan være uskyldig: inde i en tilgængelighedsgruppe med synkron commit kan den primære ikke kvittere en commit, før en fjern logskrivning er fuldført, så hver transaktion betaler en rundtur, uanset hvor mange megabit forbindelsen kan bære. Gennemstrømning måler bytes i sekundet, latens måler, hvor lang tid én udveksling tager, og en commit har kun brug for én lille udveksling for at blive færdig. Ét tal afgør diskussionen: varigheden af en lille transaktions commit, målt inde i tilgængelighedsdatabasen og igen mod en lokal tabel på samme instans.

Hvad den primære egentlig venter på

Under synkron commit holder den primære commit-kvitteringen tilbage, indtil partneren bekræfter, at dens logposter er hærdede. Hærdet betyder varigt skrevet til den sekundæres transaktionslog, ikke genkørt i dens datasider. Redo kan sakke minutter bagud uden at tilføje en enkelt millisekund til den primæres commit.

Microsofts dokumentation om tilgængelighedstilstande gennemgår det håndtryk og beskriver, hvad platformen gør, når en partner falder ud. En replika markeret som synkron er en regel om at vente, ikke et stående løfte om, at der findes en sund fjernkopi til hver commit. Den afbrudte vej er defineret separat, og det er ikke bare det, at commit fejler.

Så den ventetid, du ser, er en sum: logtransport, planlægning på begge værter og den fjernes lagerplads skrivning. En sekundær med et mættet logvolumen tilføjer tid, som ingen hastighedstest viser. Den disk bliver sjældent målt, når klagen nævner VPN'en.

Båndbredde er ikke rundtursforsinkelse

En hastighedstest oversvømmer vejen kortvarigt og rapporterer en hastighed. En commit spørger om noget snævrere: hvor lang tid en lille besked tager for at nå den anden side, blive gemt og komme tilbage. Vejlængde, kødannelse og pakketab bestemmer det tal, og ingen af dem bliver bedre, når udbyderen hæver loftet.

En «hurtig» tunnel kan derfor tilføje en synlig straf til en skrive-tung arbejdsbyrde bygget af mange små sekventielle transaktioner. Den samme samlede mængde bytes fordelt på tusind commits betaler rundturen tusind gange; én bulkoverførsel betaler den én gang.

Bed netværksejeren om forsinkelse og tab målt over selve replika-ruten under repræsentativ belastning. Et ping fra en kontorbærbar til VPN-gatewayen eller en hastighedstest til en nærliggende node tilskriver næsten intet til den rute, loggen faktisk rejser. Sørg for, at målevinduet overlapper de timer, hvor skrivning er langsom.

Læs replikaens tilstand, før du ændrer noget

Start med det, instanserne rapporterer om sig selv, fordi de to sider kan være uenige om, hvor sundt partnerskabet er, og et gennemsnit på dashboardet skjuler, hvilken kø der bevæger sig. Forespørgslerne nedenfor besvarer forskellige spørgsmål: den ene læser replikationstilstanden per database, den anden læser, hvordan hver replika er konfigureret. Kør begge, før du rører en tilstand.

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;

Det første resultat adskiller logtransport fra redo. log_send_queue_size stiger, mens redo_queue_size står fladt, betyder, at loggen ikke er ankommet; det modsatte betyder, at den er ankommet, og at afspilningen sakker bagud. Kun det første tilfælde sidder på commit-vejen.

Det andet resultat bekræfter, hvilke replikaer der faktisk er konfigureret, som du antager, fordi en tilstand, der blev ændret under en tidligere hændelse, har tendens til at forblive ændret og udokumenteret. Læs den række, du har brug for, i stedet for gruppens standard: availability_mode_desc og failover_mode_desc er per replika. secondary_lag_seconds findes kun på SQL Server 2016 og nyere, så en ældre build efterlader dig med kun kolonnerne for sendekø og redo.

Tid derefter en repræsentativ skrivning i stedet for at stole på et dashboard-gennemsnit. Kør blokken nedenfor i tilgængelighedsdatabasen, og kør den derefter igen mod den samme tabelform i en database uden for gruppen på samme instans. Forskellen mellem de to varigheder er en grov pris for den fjernes log, og den holder bedre i en diskussion med netværksteamet end en graf. Skift derefter én variabel ad gangen, ellers holder forskellen op med at betyde noget.

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;

Hvad asynkron commit køber, og hvad den koster

Med asynkron commit holder den primære op med at vente på bekræftelsen af fjern hærdning, så rundturen forlader commit-vejen. Commit-latensen falder, og den sekundære er fri til at sakke bagud i et omfang, ingen kontrollerer. Det er en reel løsning på ventetiden og en reel ændring af løftet.

Prisen er en beslutning om gendannelsespunkt. Hvis den primære dør, før dens log når et failover-mål, du faktisk kan bruge, kaster flytningen af tjenesten over på den asynkrone kopi transaktioner, som applikationen allerede har rapporteret som committede. Ingen konfigurationsdialog fremstiller det sådan, fordi det er et forretningsspørgsmål om acceptabelt tab, ikke en ydelsesindstilling. Skriv det tolererede tabsvindue ned før hændelsen, ikke under den.

Aftal tilstanden med den, der ejer dataene, skriftligt, sammen med failover-proceduren for det tilfælde, hvor det foretrukne mål er utilgængeligt. Synkron i et designdokument er ikke en driftsvejledning, og asynkron er ikke en licens til at holde op med at overvåge køerne.

Vælg en løsning, du kan forsvare bagefter

Der findes fire ærlige muligheder. Skær undgåelige commit-rundture væk, hvor applikationens semantik tillader batching; ret en transport- eller lagerflaskehals, du har målt, hvilket kan betyde et hurtigere logvolumen på den sekundære i stedet for et større rør; flyt replikaen tættere på, så rundturen krymper; eller lemp beskyttelsespolitikken og accepter et bredere tabsvindue. Hver enkelt køber latens ved at bruge noget andet, og den fjerde bruger holdbarhed. Navngiv forbruget, før du vælger.

Beslut med arbejdsbyrdens latensmål og dens holdbarhedskrav foran dig samtidig, fordi optimering af det ene stille forbruger det andet. Kør derefter den samme transaktion igen, som du målte før ændringen. En løsning, der ikke kan flytte det tal, er et gæt med en ændringsbillet.

Gem før- og efter-aflæsningerne i ændringsjournalen. Ellers gentager den næste person, der ser langsomme skrivninger, undersøgelsen fra begyndelsen og begynder med at give tunnelen skylden igen.