Kvifor den synkrone SQL-commit-en din ventar på VPN-rundturen

Skrivelatensen sprang etter at ein replika vart flytta til den andre nettstaden, og tunnelen er den nyaste komponenten, så han får skulda. Tunnelen kan vere uskuldig: inne i ei tilgjengelegheitsgruppe med synkron commit kan ikkje den primære kvittere ut ein commit før ein ekstern loggskriving er fullført, så kvar transaksjon betalar ein rundtur uansett kor mange megabit sambandet kan bere. Gjennomstrøyming måler byte per sekund, latens måler kor lang tid éi utveksling tek, og ein commit treng berre éi lita utveksling for å bli ferdig. Eitt tal avgjer diskusjonen: varigheita av ein liten transaksjons commit, målt inne i tilgjengelegheitsdatabasen og deretter på nytt mot ein lokal tabell på same instans.

Kva den primære eigentleg ventar på

Under synkron commit held den primære attende commit-kvitteringa til partnaren stadfester at loggpostane er herda. Herda tyder varig skrive til transaksjonsloggen til den sekundære, ikkje køyrt på nytt i datasidene hennar. Redo kan henge minutt etter utan å leggje til ein einaste millisekund til commit-en til den primære.

Microsoft-dokumentasjonen om tilgjengelegheitsmodusane går gjennom den handtrykken og skildrar kva plattforma gjer når ein partnar fell ut. Ein replika merkt som synkron er ei regel om å vente, ikkje eit ståande løfte om at det finst ein sunn ekstern kopi for kvar commit. Den fråkopla vegen er definert separat, og det er ikkje berre det at commit feilar.

Så ventetida du ser er ei sum: loggtransport, planlegging på begge vertane og skrivinga til ekstern lagring. Ein sekundær med metta loggvolum legg til tid som ingen hastigheitstest viser. Den disken blir sjeldan målt når klaga nemner VPN-en.

Bandbreidd er ikkje rundtursforsinking

Ein hastigheitstest oversvømmer vegen kort og rapporterer ein hastigheit. Ein commit spør om noko smalare: kor lang tid ei lita melding brukar på å nå den andre sida, bli lagra og kome tilbake. Veglengd, køar og pakketap avgjer det talet, og ingen av dei blir betre når leverandøren hevar taket.

Ein «rask» tunnel kan difor leggje til ei synleg straff på ei skrivetung arbeidsbelastning bygd av mange små sekvensielle transaksjonar. Den same bytemengda fordelt på tusen commit-ar betalar rundturen tusen gonger; éi bulkoverføring betalar han éin gong.

Be netverkeigaren om forseinking og tap målt over sjølve replikaruta under representativ last. Ein ping frå ein kontorbærbar til VPN-gatewayen, eller ein hastigheitstest til ein nærliggjande node, tilskriv nesten ingenting til ruta loggen faktisk reiser. Sørg for at målevindauget overlappar timane då skriving er treg.

Les tilstanden til replikaen før du endrar noko

Start med det instansane rapporterer om seg sjølve, fordi dei to sidene kan vere usamde om kor sunn partnarskapen er, og eit gjennomsnitt på dashbordet skjuler kva kø som flyttar seg. Spørjingane nedanfor svarar på ulike spørsmål: éi les replikasjonstilstanden per database, den andre les korleis kvar replika er konfigurert. Køyr begge før du rører ein modus.

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 resultatet skil loggtransport frå redo. log_send_queue_size som stig medan redo_queue_size står flatt tyder at loggen ikkje har kome; det motsette tyder at han har kome og at avspelinga heng etter. Berre det første tilfellet sit på commit-vegen.

Det andre resultatet stadfester kva replikaer som faktisk er konfigurerte slik du føreset, fordi ein modus som vart endra under ei tidlegare hending har ein tendens til å bli verande endra og udokumentert. Les rada du bryr deg om i staden for gruppestandarden: availability_mode_desc og failover_mode_desc er per replika. secondary_lag_seconds finst berre på SQL Server 2016 og nyare, så ein eldre versjon lèt deg sitje att med berre kolonnane for sendekø og redo.

Tid deretter ei representativ skriving i staden for å stole på eit dashbordgjennomsnitt. Køyr blokka nedanfor i tilgjengelegheitsdatabasen, og køyr ho deretter på nytt mot same tabellform i ein database utanfor gruppa på same instans. Skilnaden mellom dei to varigheitene er ein grov pris for den eksterne loggen, og i ein diskusjon med nettverksteamet held han seg mykje betre enn ein graf. Bytt deretter éin variabel om gongen, elles sluttar skilnaden å tyde noko.

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;

Kva asynkron commit kjøper, og kva han kostar

Med asynkron commit sluttar den primære å vente på stadfestinga av ekstern herding, så rundturen forlèt commit-vegen. Commit-latensen fell, og den sekundære står fritt til å henge etter i eit omfang ingen kontrollerer. Det er ei reell løysing på ventetida og ei reell endring av løftet.

Prisen er eit vedtak om gjenopprettingspunkt. Viss den primære døyr før loggen når eit failover-mål du faktisk kan bruke, kastar flyttinga av tenesta over på den asynkrone kopien transaksjonar som applikasjonen allereie har rapportert som committa. Ingen konfigurasjonsdialog framstiller det slik, fordi det er eit forretningsspørsmål om akseptabelt tap, ikkje ei ytingsinnstilling. Skriv ned det tolererte tapsvindauget før hendinga, ikkje under henne.

Avtal modusen med den som eig dataa, skriftleg, saman med failover-prosedyren for tilfellet der det føretrekte målet er utilgjengeleg. Synkron i eit design-dokument er ikkje ei driftshandbok, og asynkron er ikkje ein lisens til å slutte å overvake køane.

Vel ei løysing du kan forsvare i ettertid

Det finst fire ærlege alternativ. Kutt unødvendige commit-rundturar der semantikken til applikasjonen tillèt batching; fiks ein målt flaskehals i transport eller lagring, noko som kan tyde eit raskare loggvolum på den sekundære i staden for eit større røyr; flytt replikaen nærare så rundturen krympar; eller lemp beskyttelsespolitikken og aksepter eit breiare tapsvindauge. Kvar av dei kjøper latens ved å bruke noko anna, og den fjerde brukar haldbarheit. Namngje forbruket før du vel.

Avgjer med latensmålet til arbeidsbelastninga og haldbarheitskravet hennar framfor deg samstundes, fordi optimalisering av det eine stille brukar det andre. Køyr deretter den same transaksjonen på nytt som du målte før endringa. Ei løysing som ikkje kan flytte det talet, er ei gjetning med ein endringsbillett.

Ta vare på føre- og etteravlesingane i endringsloggen. Elles gjer den neste personen som ser trege skrivingar, undersøkinga om att frå byrjinga og byrjar igjen med å gje tunnelen skulda.