Kodėl greitas VPN vis tiek lėtina sinchroninį SQL sandorio patvirtinimą

Atidarykite užklausos sesiją pagrindiniame ir pažiūrėkite, ko laukia paprastas įrašymas. Jei duomenų bazė priklauso sinchroninio patvirtinimo prieinamumo grupei ir antrinė yra prijungta, dalis to laukimo palieka pastatą: žurnalo įrašai keliauja į kopiją, ten sukietinami, ir žinia apie tą sukietinimą grįžta prieš pasibaigiant patvirtinimui. Pralaidumas nesutrumpina šios kelionės pirmyn ir atgal. Toliau pateikta apžvalga seka patvirtinimą nuo ekrano iki nuotolinio disko ir atgal.

Pradėkite nuo laukimo tipo pagrindiniame

Nuotolinėje kopijoje laukiantis įrašymas pasirodo kaip su žurnalu susijęs laukimas, o ne procesoriaus ar užrakto laukimas, ir sandorio trukmė seka kelionę pirmyn ir atgal, o ne eilučių skaičių. Daug mažų patvirtinimų tai padaro akivaizdu, nes kiekvienas atskirai apmoka kelionę. Viena didelė operacija paslepia tą pačią kainą viename ilgesniame patvirtinime.

Prieš darydami bet kokią išvadą apie ryšį, surikiuokite darbo krūvį pagal patvirtinimų dažnį.

Perskaitykite kopijos būseną prieš skaitydami tinklą. Svarbūs skaitikliai yra siuntimo eilė, redo eilė ir sinchronizacijos būsena, ir kartu jie rodo, ar antrinė spėja, ar atsilieka. Auganti siuntimo eilė nurodo transportą, o auganti redo eilė – pačios antrinės darbą ar saugyklą. Tai skirtingi remontai, ir nė vienas nepagerėja pridėjus pralaidumo.

Sekite patvirtinimą iki antrinės

Esant sinchroniniam patvirtinimui, pagrindinis laukia patvirtinimo, kad atitinkamas žurnalas buvo sukietintas antrinėje, prieš pranešdamas, kad patvirtinimas baigtas. Sukietinta reiškia ilgaamžė žurnale, o ne peržaista į duomenų puslapius. Būtent šis skirtumas paaiškina, kodėl sinchroninė antrinė gali atsilikti redo srityje ir vis tiek tvirtinti sukietinimą.

Pereikite kelią iš eilės ir matuokite kiekvieną etapą, o ne visumą. Žurnalo įrašai eina per transportą, antrinė juos rašo ir išstumia, o patvirtinimas grįžta tuo pačiu keliu. Transporto vėlavimas, antrinės planavimas ir antrinės žurnalo disko delsa visi patenka į sumą, ir tik pirmasis priklauso tinklo savininkui. Antrinė, kurios žurnalo apimtis prisotinta kuo kitu, gali ištempti kiekvieną patvirtinimą, kol ryšys stovi nenaudojamas.

SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
       drs.log_send_queue_size, drs.redo_queue_size
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;

Padarykite tą momentinę kopiją prieš ir po reprezentatyvaus įrašymo, o ne vieną kartą ramų popietę. Skirtumas yra tai, kas pasako, kuri eilė pajudėjo, kol patvirtinimas laukė.

Matuokite kelią, o ne ryšį

Pralaidumo testas matuoja talpą tarp dviejų taškų, kurie nėra jūsų kopijos, esant apkrovai, kuri nėra jūsų darbas. Paprašykite tinklo savininko vėlavimo ir nuostolių tikruoju kopijos keliu, kol vyksta tikras srautas, abiem kryptimis. Nuostoliai čia svarbesni už talpą, nes prarastas segmentas kainuoja persiuntimą ir kiekvienas patvirtinimas laukia vieno patvirtinimo. Ryšys, kuris atsisiuntimo teste atrodo puikiai, vis tiek gali netikti kalbiam patvirtinimų modeliui.

Matuodami išlaikykite nepažeistą duomenų bazės transporto saugumą ir prieigos kontrolę. Kelio matavimas niekada nėra priežastis jų apeiti.

Susiekite laikus su skaitikliais, o ne su intuicija. Jei siuntimo eilė lieka tuščia, o patvirtinimas vis dar laukia, vėlavimas yra patvirtinime arba antrinės išstūmime. Jei siuntimo eilė nuolat auga, apribojimas yra transportas arba talpa. Užrašykite, kuris stebėjimas parėmė išvadą, kad kitas žmogus galėtų pakartoti matavimą, o ne ginčą.

Ką asinchroninis režimas iš tikrųjų keičia

Asinchroninis patvirtinimas pašalina antrinės sukietinimo patvirtinimo laukimą, todėl įrašymai pagreitėja ir todėl keičiasi jūsų patvarumo pozicija. Pagrindinis patvirtina sandorį be to nuotolinio patvirtinimo. Tada antrinei leidžiama atsilikti, ir tas atsilikimas yra poveikis.

Jei pagrindinis prarandamas anksčiau, nei žurnalas pasiekia naudojamą perjungimo tikslą, paslaugos privertimas perkelti į tą kopiją išmeta sandorius, apie kuriuos programai jau buvo pranešta, kad jie patvirtinti.

Tai sprendimas dėl atkūrimo taško ir jis priklauso duomenų bazės savininkui, o ne našumo peržiūrai. Pirmiausia nustatykite toleruojamą duomenų praradimo langą, pasirinkite režimą, kuris jį tenkina, tada optimizuokite tos ribos viduje. Parinktys, išlaikančios sinchroninę apsaugą, apima vengtinų patvirtinimo kelionių panaikinimą ten, kur programa leidžia, išmatuoto transporto ar saugyklos susiaurėjimo ištaisymą ir kopijos perkėlimą, kad patvirtinimas nukeliautų mažesnį atstumą. Pasverkite jas pagal pradinį patvarumo reikalavimą, kuris nepasikeitė.