Kodėl jūsų sinchroninis SQL commit laukia VPN kelionės pirmyn ir atgal

Rašymo delsa šoktelėjo po to, kai replika buvo perkelta į antrą vietą, o tunelis yra naujausias komponentas, todėl jam tenka kaltė. Tunelis gali būti nekaltas: prieinamumo grupėje su sinchroniniu commit pirminė replika negali patvirtinti commit, kol nebaigtas nuotolinis žurnalo įrašymas, todėl kiekviena transakcija moka kelionę pirmyn ir atgal, nesvarbu kiek megabitų jungtis gali perduoti. Pralaidumas matuoja baitus per sekundę, delsa matuoja, kiek trunka vienas apsikeitimas, o commit užbaigti tereikia vieno mažo apsikeitimo. Vienas skaičius išsprendžia ginčą: mažos transakcijos commit trukmė, išmatuota prieinamumo duomenų bazėje ir dar kartą prieš vietinę lentelę toje pačioje instancijoje.

Ko pirminė replika iš tikrųjų laukia

Esant sinchroniniam commit, pirminė replika sulaiko commit patvirtinimą, kol partnerė patvirtina, kad jos žurnalo įrašai sukietinti. Sukietinti reiškia patikimai įrašyti į antrinės transakcijų žurnalą, o ne perleisti į jos duomenų puslapius. Redo gali atsilikti minutėmis, nepridėdamas nė milisekundės prie pirminės commit.

Microsoft dokumentacija apie prieinamumo režimus paaiškina tą rankos paspaudimą ir ką platforma daro, kai partnerė iškrenta. Replika, pažymėta kaip sinchroninė, yra laukimo taisyklė, o ne nuolatinis pažadas, kad kiekvienam commit egzistuoja sveika nuotolinė kopija. Nutrauktas kelias apibrėžiamas atskirai, ir tai nėra tiesiog tai, kad commit nepavyksta.

Taigi laukimas, kurį matote, yra suma: žurnalo perdavimas, planavimas abiejuose hostuose ir įrašymas į nuotolinę saugyklą. Antrinė su prisotintu žurnalo kiekiu prideda laiko, kurio neparodys joks greičio testas. Tas diskas retai matuojamas, kai skunde minimas VPN.

Pralaidumas nėra kelionės pirmyn ir atgal delsa

Greičio testas trumpam užlieja kelią ir praneša spartą. Commit prašo kažko siauresnio: kiek laiko mažai žinutei reikia pasiekti kitą pusę, būti išsaugotai ir grįžti. Kelio ilgis, eilės ir paketų nuostoliai nustato tą skaičių, ir nė vienas jų nepagerėja, kai tiekėjas pakelia lubas.

Todėl „greitas“ tunelis gali pridėti matomą baudą rašymui sunkiai darbo apkrovai, sudarytai iš daug mažų nuoseklių transakcijų. Ta pati baitų suma, padalinta tūkstančiui commit, moka kelionę pirmyn ir atgal tūkstantį kartų; vienas masinis perkėlimas sumoka ją vieną kartą.

Paprašykite tinklo savininko išmatuoti delsą ir nuostolius pačiame replikos maršrute esant reprezentatyviai apkrovai. Ping iš biuro nešiojamojo kompiuterio į VPN šliuzą arba greičio testas į netolimą mazgą beveik nieko nepriskiria maršrutui, kuriuo žurnalas iš tikrųjų keliauja. Pasirūpinkite, kad matavimo langas sutaptų su valandomis, kai rašymas lėtas.

Perskaitykite replikos būseną prieš ką nors keisdami

Pradėkite nuo to, ką instancijos praneša apie save, nes abi pusės gali nesutarti, kokia sveika partnerystė yra, ir skydelio vidurkis paslepia, kuri eilė juda. Toliau pateiktos užklausos atsako į skirtingus klausimus: viena skaito replikacijos būseną pagal duomenų bazę, kita skaito, kaip sukonfigūruota kiekviena replika. Paleiskite abi prieš liesdami režimą.

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;

Pirmasis rezultatas atskiria žurnalo perdavimą nuo redo. log_send_queue_size augant, o redo_queue_size išliekant plokščiam, reiškia, kad žurnalas neatvyko; priešingai reiškia, kad jis atvyko ir peržaidimas atsilieka. Tik pirmasis atvejis yra commit kelyje.

Antrasis rezultatas patvirtina, kurios replikos iš tikrųjų sukonfigūruotos taip, kaip manote, nes ankstesnio incidento metu pakeistas režimas linkęs likti pakeistas ir nedokumentuotas. Skaitykite eilutę, kuri jums rūpi, o ne grupės numatytąją: availability_mode_desc ir failover_mode_desc yra kiekvienai replikai. secondary_lag_seconds egzistuoja tik SQL Server 2016 ir naujesnėse versijose, todėl senesnė versija jums palieka tik siuntimo eilės ir redo stulpelius.

Tada išmatuokite reprezentatyvų rašymą, o ne pasikliaukite skydelio vidurkiu. Paleiskite žemiau esantį bloką prieinamumo duomenų bazėje, tada paleiskite jį dar kartą prieš tą pačią lentelės formą duomenų bazėje už grupės ribų toje pačioje instancijoje. Skirtumas tarp dviejų trukmių yra apytikslė nuotolinio žurnalo kaina, ir ginče su tinklo komanda jis laikosi daug geriau nei grafikas. Po to keiskite po vieną kintamąjį, kitaip skirtumas nebetenka prasmės.

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;

Ką perka asinchroninis commit ir kiek tai kainuoja

Su asinchroniniu commit pirminė replika nustoja laukti nuotolinio sukietinimo patvirtinimo, todėl kelionė pirmyn ir atgal išeina iš commit kelio. Commit delsa krinta, o antrinė gali laisvai atsilikti tiek, kiek niekas nekontroliuoja. Tai tikra laukimo pataisa ir tikras pažado pakeitimas.

Kaina yra sprendimas dėl atkūrimo taško. Jei pirminė replika miršta anksčiau, nei jos žurnalas pasiekia perjungimo gedimo atveju tikslą, kurį iš tikrųjų galite naudoti, paslaugos perkėlimas į asinchroninę kopiją išmeta transakcijas, kurias programa jau pranešė kaip commit. Joks konfigūracijos dialogas to taip nepateikia, nes tai verslo klausimas apie priimtiną nuostolį, o ne našumo nustatymas. Užsirašykite toleruojamą nuostolių langą prieš incidentą, o ne jo metu.

Suderinkite režimą su duomenų savininku raštu, kartu su perjungimo gedimo atveju procedūra tam atvejui, kai pageidaujamas tikslas nepasiekiamas. Sinchroninis projektavimo dokumente nėra operacinis vadovas, o asinchroninis nėra licencija nustoti stebėti eiles.

Pasirinkite pataisą, kurią vėliau galėsite apginti

Yra keturi sąžiningi variantai. Nukirpkite išvengiamas commit keliones pirmyn ir atgal ten, kur programos semantika leidžia paketavimą; ištaisykite išmatuotą perdavimo ar saugyklos kliūtį, o tai gali reikšti greitesnį žurnalo kiekį antrinėje, o ne didesnį vamzdį; priartinkite repliką, kad kelionė pirmyn ir atgal sumažėtų; arba sušvelninkite apsaugos politiką ir priimkite platesnį nuostolių langą. Kiekvienas perka delsą išleisdamas ką nors kita, o ketvirtasis išleidžia patvarumą. Įvardinkite išlaidas prieš rinkdamiesi.

Spręskite turėdami prieš akis kartu darbo krūvio delsos tikslą ir jo patvarumo reikalavimą, nes vieno optimizavimas tyliai išleidžia kitą. Tada dar kartą paleiskite tą pačią transakciją, kurią išmatavote prieš pakeitimą. Pataisa, kuri negali pajudinti to skaičiaus, yra spėjimas su pakeitimo bilietu.

Išsaugokite prieš ir po rodmenis pakeitimo įraše. Priešingu atveju kitas žmogus, pamatęs lėtą rašymą, pakartoja tyrimą nuo pradžių ir vėl pradeda kaltinti tunelį.