Waarom jou sinchrone SQL-vastelegging op die VPN-retourreis wag

Die skryf-latensie het opgespring nadat 'n replika na die tweede terrein geskuif het, en die tonnel is die nuutste komponent, so dit kry die skuld. Die tonnel kan onskuldig wees: binne 'n sinchrone-vasteleg-beskikbaarheidsgroep kan die primêre nie 'n vastelegging erken voordat 'n afgeleë log-skryf voltooi is nie, so elke transaksie betaal 'n retourreis maak nie saak hoeveel megabis die skakel kan dra nie. Deurset meet grepe per sekonde, latensie meet hoe lank een uitruiling duur, en 'n vastelegging het net een klein uitruiling nodig om klaar te maak. Een getal besleg die argument: die vasteleggingstyd van 'n klein transaksie, gemeet binne die beskikbaarheidsdatabasis en weer teen 'n plaaslike tabel op dieselfde instansie.

Waarvoor die primêre werklik wag

Onder sinchrone vastelegging hou die primêre die vasteleggingsbevestiging terug totdat die vennoot bevestig dat sy logrekords gehard is. Gehard beteken duursaam na die sekondêre se transaksielog geskryf, nie in sy databladsye herdoen nie. Redo kan met minute agterbly sonder om 'n millisekonde by die primêre se vastelegging te voeg.

Microsoft se dokumentasie oor beskikbaarheidsmodusse verduidelik daardie handdruk en beskryf wat die platform doen wanneer 'n vennoot uitval. 'n Replika wat as sinchroon gemerk is, is 'n reël oor wag, nie 'n staande belofte dat daar vir elke vastelegging 'n gesonde afgeleë kopie bestaan nie. Die ontkoppelde pad word afsonderlik gedefinieer, en dit is nie bloot dat die vastelegging misluk nie.

Die wag wat jy sien, is dus 'n som: logvervoer, skedulering op albei gashere en die afgeleë stoorskryf. 'n Sekondêre met 'n versadigde logvolume voeg tyd by wat geen spoedtoets sal wys nie. Daardie skyf word selde gemeet wanneer die klagte die VPN noem.

Bandwydte is nie retourvertraging nie

'n Spoedtoets oorstroom die pad kortliks en rapporteer 'n tempo. 'n Vastelegging vra iets smaller: hoe lank een klein boodskap neem om die oorkant te bereik, geberg te word en terug te kom. Padlengte, toustaan en pakketverlies bepaal daardie getal, en nie een daarvan verbeter wanneer die verskaffer die plafon verhoog nie.

'n “Vinnige” tonnel kan dus 'n sigbare prys byvoeg by 'n skryfsware werklading wat uit baie klein opeenvolgende transaksies bestaan. Dieselfde grepetotaal verdeel oor duisend vasteleggings betaal die retourreis duisend keer; een groot oordrag betaal dit een keer.

Vra die netwerkeienaar vir vertraging en verlies gemeet oor die replikaroete self onder verteenwoordigende las. 'n Ping vanaf 'n kantoorlaptop na die VPN-grendel, of 'n spoedtoets na 'n nabye nodus, skryf byna niks toe aan die roete wat die log werklik reis nie. Kry dat die meetvenster die ure oorvleuel wanneer skrywe stadig is.

Lees die replikatoestand voordat jy iets verander

Begin by wat die instansies oor hulself rapporteer, want die twee kante kan verskil oor hoe gesond die vennootskap is en 'n paneelgemiddelde verberg watter tou beweeg. Die navrae hieronder beantwoord verskillende vrae: een lees die per-databasis-replikasietoestand, die ander lees hoe elke replika opgestel is. Voer albei uit voordat jy aan 'n modus raak.

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;

Die eerste resultaat skei logvervoer van redo. log_send_queue_size wat klim terwyl redo_queue_size plat bly, beteken die log het nie aangekom nie; die omgekeerde beteken dit het aangekom en herspeling is agter. Net die eerste geval sit op die vasteleggingspad.

Die tweede resultaat bevestig watter replikas werklik opgestel is soos jy aanneem, want 'n modus wat tydens 'n vroeëre voorval verander is, bly geneig om verander en ongedokumenteer te bly. Lees die ry waaraan jy omgee eerder as die groepverstek: availability_mode_desc en failover_mode_desc is per replika. secondary_lag_seconds bestaan net op SQL Server 2016 en later, so 'n ouer bou laat jou met net die stuur- en redotou-kolomme.

Meet dan 'n verteenwoordigende skryf eerder as om 'n paneelgemiddelde te vertrou. Voer die blok hieronder in die beskikbaarheidsdatabasis uit, en voer dit dan weer uit teen dieselfde tabelvorm in 'n databasis buite die groep op dieselfde instansie. Die gaping tussen die twee tydsduur is 'n ruwe prys vir die afgeleë log, en dit hou beter stand in 'n argument met die netwerkspan as wat 'n grafiek doen. Verander daarna een veranderlike op 'n slag, of die gaping hou op om enigiets te beteken.

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;

Wat asinchrone vastelegging koop, en wat dit kos

Met asinchrone vastelegging hou die primêre op om vir die bevestiging van afgeleë harding te wag, so die retourreis verlaat die vasteleggingspad. Vasteleggingslatensie daal en die sekondêre is vry om agter te raak met 'n mate wat niemand beheer nie. Dit is 'n werklike oplossing vir die wag en 'n werklike verandering aan die belofte.

Die prys is 'n herstelpuntbesluit. As die primêre sterf voordat sy log 'n oorneemteiken bereik wat jy werklik kan gebruik, gooi die diens na die asinchrone kopie transaksies weg wat die toepassing reeds as vastegelê gerapporteer het. Geen opstelvenster stel dit so voor nie, want dit is 'n besigheidsvraag oor aanvaarbare verlies eerder as 'n werkverrigtinginstelling. Skryf die aanvaarbare verliesvenster neer voor die voorval, nie tydens dit nie.

Stem die modus saam met wie ook al die data besit, skriftelik, saam met die oorneemprosedure vir die geval waar die voorkeurteiken onbeskikbaar is. Sinchroon in 'n ontwerpdocument is nie 'n bedryfshandleiding nie, en asinchroon is nie 'n lisensie om op te hou om die toue dop te hou nie.

Kies 'n oplossing wat jy agterna kan verdedig

Vier eerlike opsies bestaan. Sny vermybare vasteleggingsretourreise waar die toepassing se semantiek bondeling toelaat; herstel 'n vervoer- of stoorknelpunt wat jy gemeet het, wat dalk 'n vinniger logvolume op die sekondêre beteken eerder as 'n groter pyp; skuif die replika nader sodat die retourreis krimp; of verslap die beskermingsbeleid en aanvaar 'n wyer verliesvenster. Elkeen koop latensie deur iets anders te bestee, en die vierde bestee duursaamheid. Noem die besteding voordat jy kies.

Besluit met die werklading se latensieteiken en sy duursaamheidsvereiste terselfdertyd voor jou, want om die een te optimaliseer bestee stilweg die ander. Voer dan dieselfde transaksie weer uit wat jy voor die verandering gemeet het. 'n Oplossing wat daardie getal nie kan beweeg nie, is 'n raaiskoot met 'n veranderingskaartjie aan.

Hou die voor-en-na-lesings in die veranderingsrekord. Anders herhaal die volgende persoon wat stadige skrywe sien, die ondersoek van die begin af en begin weer die tonnel blameer.