Kāpēc ātrs VPN joprojām palēnina sinhrono SQL darījuma apstiprinājumu

Atveriet vaicājuma sesiju primārajā un apskatiet, ko gaida vienkāršs ieraksts. Ja datubāze pieder sinhronā apstiprinājuma pieejamības grupai un sekundārais ir savienots, daļa no šīs gaidīšanas atstāj ēku: žurnāla ieraksti ceļo uz kopiju, tur tiek nocietināti, un ziņa par šo nocietināšanu atgriežas pirms apstiprinājuma beigām. Joslas platums šo ceļu turp un atpakaļ nesamazina. Tālāk sniegtais pārskats seko apstiprinājumam no ekrāna līdz attālajam diskam un atpakaļ.

Sāciet ar gaidīšanas tipu primārajā

Ieraksts, kas gaida attālajā kopijā, parādās kā ar žurnālu saistīta gaidīšana, nevis CPU vai bloķēšanas gaidīšana, un darījuma ilgums seko ceļam turp un atpakaļ, nevis rindu skaitam. Daudzi mazi apstiprinājumi to padara acīmredzamu, jo katrs atsevišķi maksā par ceļu. Viena liela operācija paslēpj tās pašas izmaksas vienā garākā apstiprinājumā.

Pirms izdarāt jebkādu secinājumu par saiti, sakārtojiet darba slodzi pēc apstiprinājumu biežuma.

Izlasiet kopijas stāvokli pirms tīkla lasīšanas. Svarīgie skaitītāji ir sūtīšanas rinda, redo rinda un sinhronizācijas stāvoklis, un kopā tie parāda, vai sekundārais pagūst vai atpaliek. Augoša sūtīšanas rinda norāda uz transportu, bet augoša redo rinda uz paša sekundārā darbu vai krātuvi. Tie ir dažādi remonti, un neviens neuzlabojas, pievienojot joslas platumu.

Izsekojiet apstiprinājumam līdz sekundārajam

Sinhronā apstiprinājuma gadījumā primārais gaida apstiprinājumu, ka attiecīgais žurnāls ir nocietināts sekundārajā, pirms paziņo apstiprinājumu kā pabeigtu. Nocietināts nozīmē noturīgs žurnālā, nevis atkārtoti izpildīts datu lapās. Tieši šī atšķirība izskaidro, kāpēc sinhronais sekundārais var atpalikt redo jomā un tomēr apstiprināt nocietināšanu.

Ejiet pa ceļu secībā un mēriet katru posmu, nevis kopumu. Žurnāla ieraksti iet caur transportu, sekundārais tos raksta un izskalo, un apstiprinājums atgriežas pa to pašu ceļu. Transporta aizture, sekundārā plānošana un sekundārā žurnāla diska latentums visi nonāk summā, un tikai pirmais pieder tīkla īpašniekam. Sekundārais, kura žurnāla apjoms ir piesātināts ar kaut ko citu, var izstiept katru apstiprinājumu, kamēr saite stāv dīkā.

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;

Uzņemiet šo momentuzņēmumu pirms un pēc reprezentatīva ieraksta, nevis vienreiz mierīgā pēcpusdienā. Tieši starpība pasaka, kura rinda pārvietojās, kamēr apstiprinājums gaidīja.

Mēriet ceļu, nevis saiti

Caurlaidības tests mēra kapacitāti starp diviem punktiem, kas nav jūsu kopijas, slodzes apstākļos, kas nav jūsu darbs. Lūdziet tīkla īpašniekam aizturi un zudumus pa īsto kopijas ceļu, kamēr plūst īsts trafiks, abos virzienos. Zudumi šeit ir svarīgāki par kapacitāti, jo zaudēts segments izmaksā atkārtotu pārraidi un katrs apstiprinājums gaida vienu apstiprinājumu. Saite, kas lejupielādes testā izskatās lieliski, tomēr var būt nepiemērota runīgam apstiprinājumu modelim.

Mērīšanas laikā saglabājiet datubāzes transporta drošību un piekļuves kontroli neskartu. Ceļa mērīšana nekad nav iemesls tās apiet.

Saistiet laikus ar skaitītājiem, nevis ar intuīciju. Ja sūtīšanas rinda paliek tukša un apstiprinājums joprojām gaida, aizture ir apstiprinājumā vai sekundārā izskalošanā. Ja sūtīšanas rinda vienmērīgi aug, ierobežojums ir transports vai kapacitāte. Pierakstiet, kuri novērojumi atbalstīja secinājumu, lai nākamais cilvēks varētu atkārtot mērījumu, nevis strīdu.

Ko asinhronais režīms patiešām maina

Asinhronais apstiprinājums noņem gaidīšanu uz sekundārā nocietināšanas apstiprinājumu, tāpēc ieraksti kļūst ātrāki un tāpēc mainās jūsu noturības pozīcija. Primārais apstiprina darījumu bez šī attālā apstiprinājuma. Tad sekundārajam ir atļauts atpalikt, un šī atpalikšana ir iedarbība.

Ja primārais tiek zaudēts pirms žurnāls sasniedz lietojamu pārslēgšanās mērķi, pakalpojuma piespiedu pārvietošana uz šo kopiju izmet darījumus, par kuriem lietotnei jau bija paziņots, ka tie ir apstiprināti.

Tas ir lēmums par atjaunošanas punktu, un tas pieder datubāzes īpašniekam, nevis veiktspējas pārskatam. Vispirms iestatiet pieļaujamo datu zuduma logu, izvēlieties režīmu, kas to apmierina, un pēc tam optimizējiet šajā robežā. Opcijas, kas saglabā sinhrono aizsardzību, ietver izvairāmu apstiprinājuma braucienu novēršanu tur, kur lietotne to atļauj, izmērītas transporta vai krātuves šaurās vietas labošanu un kopijas pārvietošanu, lai apstiprinājums veiktu mazāku attālumu. Izsveriet tās pret sākotnējo noturības prasību, kas nav mainījusies.