Zakaj vaša sinhrona potrditev SQL čaka na pot VPN tja in nazaj

Zakasnitev pisanja je poskočila, potem ko se je replika preselila na drugo lokacijo, in tunel je najnovejša komponenta, zato nosi krivdo. Tunel je lahko nedolžen: v skupini razpoložljivosti s sinhrono potrditvijo primarna ne more potrditi potrditve, dokler ni končano oddaljeno pisanje dnevnika, zato vsaka transakcija plača pot tja in nazaj, ne glede na to, koliko megabitov lahko povezava prenese. Prepustnost meri bajte na sekundo, zakasnitev meri, koliko traja ena izmenjava, in potrditev potrebuje za dokončanje le eno majhno izmenjavo. Eno število odloči spor: trajanje potrditve majhne transakcije, izmerjeno v bazi razpoložljivosti in nato znova proti lokalni tabeli na isti instanci.

Na kaj primarna v resnici čaka

Pri sinhroni potrditvi primarna zadrži potrditev, dokler partner ne potrdi, da so njegovi zapisi v dnevniku utrjeni. Utrjeni pomeni trajno zapisani v transakcijski dnevnik sekundarne, ne ponovno izvedeni v njenih podatkovnih straneh. Redo lahko zaostaja minute, ne da bi primarni potrditvi dodal eno samo milisekundo.

Microsoftova dokumentacija o načinih razpoložljivosti razloži to rokovanje in opiše, kaj platforma naredi, ko partner odpade. Replika, označena kot sinhrona, je pravilo o čakanju, ne trajna obljuba, da za vsako potrditev obstaja zdrava oddaljena kopija. Prekinjena pot je opredeljena ločeno in ni le to, da potrditev spodleti.

Torej je čakanje, ki ga vidite, vsota: prenos dnevnika, razporejanje na obeh gostiteljih in pisanje v oddaljeno shrambo. Sekundarna z nasičeno količino dnevnika doda čas, ki ga noben preizkus hitrosti ne pokaže. Ta disk se redko meri, ko pritožba omeni VPN.

Prepustnost ni zakasnitev poti tja in nazaj

Preizkus hitrosti za kratek čas preplavi pot in poroča hitrost. Potrditev zahteva nekaj ožjega: koliko časa majhno sporočilo potrebuje, da pride na drugo stran, se shrani in vrne. Dolžina poti, čakalne vrste in izguba paketov določajo to število in nobeno od tega se ne izboljša, ko ponudnik dvigne zgornjo mejo.

«Hitri» tunel lahko zato doda vidno kazen obremenitvi, ki veliko piše in je sestavljena iz mnogih majhnih zaporednih transakcij. Ista skupna količina bajtov, razdeljena na tisoč potrditev, plača pot tja in nazaj tisočkrat; en prenos v kosu jo plača enkrat.

Prosite lastnika omrežja za zakasnitev in izgubo, izmerjeni na sami poti replike pod reprezentativno obremenitvijo. Ping z pisarniškega prenosnika do prehoda VPN ali preizkus hitrosti do bližnjega vozlišča skoraj nič ne pripiše poti, po kateri dnevnik v resnici potuje. Poskrbite, da se merilno okno prekriva z urami, ko je pisanje počasno.

Preberite stanje replike, preden karkoli spremenite

Začnite s tem, kar instance poročajo o sebi, ker se strani lahko ne strinjata o tem, kako zdravo je partnerstvo, in povprečje na nadzorni plošči skriva, katera vrsta se premika. Spodnje poizvedbe odgovarjajo na različna vprašanja: ena bere stanje replikacije po bazah, druga bere, kako je konfigurirana vsaka replika. Zaženite obe, preden se dotaknete načina.

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;

Prvi rezultat loči prenos dnevnika od redo. log_send_queue_size raste, medtem ko redo_queue_size stoji ravno, pomeni, da dnevnik ni prispel; nasprotno pomeni, da je prispel in da predvajanje zaostaja. Le prvi primer sedi na poti potrditve.

Drugi rezultat potrdi, katere replike so res konfigurirane tako, kot predvidevate, ker način, spremenjen med prejšnjim incidentom, običajno ostane spremenjen in nedokumentiran. Berite vrstico, ki vas zanima, namesto privzete vrednosti skupine: availability_mode_desc in failover_mode_desc sta za vsako repliko. secondary_lag_seconds obstaja le v SQL Server 2016 in novejšem, zato vam starejša različica pusti le stolpca čakalne vrste pošiljanja in redo.

Nato izmerite reprezentativno pisanje, namesto da bi zaupali povprečju z nadzorne plošče. Zaženite spodnji blok v bazi razpoložljivosti in ga nato znova zaženite proti enaki obliki tabele v bazi zunaj skupine na isti instanci. Razlika med obema trajanjema je groba cena oddaljenega dnevnika in v razpravi z omrežno ekipo zdrži veliko bolje kot graf. Nato spreminjajte eno spremenljivko naenkrat, sicer razlika ne pomeni več ničesar.

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;

Kaj kupi asinhrona potrditev in koliko stane

Pri asinhroni potrditvi primarna preneha čakati na potrditev oddaljenega utrjevanja, zato pot tja in nazaj zapusti pot potrditve. Zakasnitev potrditve pade in sekundarna lahko prosto zaostaja za količino, ki je nihče ne nadzoruje. To je resnična popravek čakanja in resnična sprememba obljube.

Cena je odločitev o obnovitveni točki. Če primarna umre, preden njen dnevnik doseže cilj preklopa ob napaki, ki ga res lahko uporabite, premik storitve na asinhrono kopijo zavrže transakcije, ki jih je aplikacija že sporočila kot potrjene. Nobeno konfiguracijsko okno tega ne predstavi tako, ker je to poslovno vprašanje o sprejemljivi izgubi, ne nastavitev zmogljivosti. Zapišite tolerirano okno izgube pred incidentom, ne med njim.

Dogovorite način z lastnikom podatkov pisno, skupaj s postopkom preklopa ob napaki za primer, ko želeni cilj ni na voljo. Sinhrono v projektnem dokumentu ni operativni priročnik in asinhrono ni licenca za prenehanje opazovanja vrst.

Izberite popravek, ki ga boste lahko pozneje zagovarjali

Obstajajo štiri poštene možnosti. Odrežite nepotrebne poti potrditve tja in nazaj tam, kjer semantika aplikacije dovoljuje združevanje; popravite izmerjeno ozko grlo prenosa ali shrambe, kar lahko pomeni hitrejšo količino dnevnika na sekundarni namesto večje cevi; približajte repliko, da se pot tja in nazaj skrajša; ali omilite zaščitno politiko in sprejmite širše okno izgube. Vsaka kupi zakasnitev z porabo nečesa drugega, četrta pa porabi trajnost. Poimenujte porabo, preden izberete.

Odločajte se s ciljem zakasnitve obremenitve in njeno zahtevo po trajnosti hkrati pred seboj, ker optimizacija enega tiho porabi drugo. Nato znova zaženite isto transakcijo, ki ste jo izmerili pred spremembo. Popravek, ki ne more premakniti te številke, je ugibanje z vozovnico za spremembo.

Shranite odčitke pred in po v zapisu spremembe. Sicer naslednja oseba, ki vidi počasne zapise, ponovi preiskavo od začetka in spet začne kriviti tunel.