Kāpēc jūsu sinhronais SQL commit gaida VPN ceļu turp un atpakaļ

Rakstīšanas latence uzlēca pēc tam, kad replika tika pārvietota uz otru vietu, un tunelis ir jaunākā komponente, tāpēc vaina tiek uzlikta tam. Tunelis var būt nevainīgs: pieejamības grupā ar sinhronu commit primārā replika nevar apstiprināt commit, kamēr nav pabeigta attālinātā žurnāla rakstīšana, tāpēc katra transakcija maksā ceļu turp un atpakaļ neatkarīgi no tā, cik megabitu savienojums var pārnest. Caurlaidspēja mēra baitus sekundē, latence mēra, cik ilgi ilgst viena apmaiņa, un commit pabeigšanai nepieciešama tikai viena maza apmaiņa. Viens skaitlis izšķir strīdu: mazas transakcijas commit ilgums, mērīts pieejamības datubāzē un pēc tam vēlreiz pret vietējo tabulu tajā pašā instancē.

Ko primārā replika patiešām gaida

Sinhrona commit gadījumā primārā replika aiztur commit apstiprinājumu, līdz partnere apstiprina, ka tās žurnāla ieraksti ir sacietējuši. Sacietējuši nozīmē ilgstoši ierakstīti sekundārās transakciju žurnālā, nevis atkārtoti izpildīti tās datu lapās. Redo var atpalikt minūtes, nepievienojot ne milisekundi primārās commit.

Microsoft dokumentācija par pieejamības režīmiem izskaidro šo roku sasviešanos un apraksta, ko platforma dara, kad partnere izkrīt. Replika, kas atzīmēta kā sinhrona, ir noteikums par gaidīšanu, nevis pastāvīgs solījums, ka katram commit pastāv vesela attālināta kopija. Atvienotais ceļš ir definēts atsevišķi, un tas nav vienkārši tas, ka commit neizdodas.

Tātad gaidīšana, ko redzat, ir summa: žurnāla pārnese, plānošana abos resursos un rakstīšana attālinātajā krātuvē. Sekundārā ar piesātinātu žurnāla apjomu pievieno laiku, ko neparādīs neviens ātruma tests. Šis disks tiek reti mērīts, kad sūdzībā minēts VPN.

Joslas platums nav ceļa turp un atpakaļ aizture

Ātruma tests uz brīdi pārpludina ceļu un ziņo par ātrumu. Commit lūdz kaut ko šaurāku: cik ilgi mazai ziņai vajag, lai sasniegtu otru pusi, tiktu saglabāta un atgrieztos. Ceļa garums, rindas un pakešu zudumi nosaka šo skaitli, un neviens no tiem neuzlabojas, kad pakalpojumu sniedzējs paceļ griestus.

Tāpēc «ātrs» tunelis var pievienot redzamu sodu rakstīšanas smagai darba slodzei, kas veidota no daudzām mazām secīgām transakcijām. Tā pati baitu summa, sadalīta tūkstotī commit, maksā ceļu turp un atpakaļ tūkstoš reižu; viena lielapjoma pārnese samaksā to vienreiz.

Lūdziet tīkla īpašniekam izmērīt aizturi un zudumus pašā replikas maršrutā pie reprezentatīvas slodzes. Ping no biroja portatīvā datora uz VPN vārteju vai ātruma tests uz tuvējo mezglu gandrīz neko nepiešķir maršrutam, pa kuru žurnāls patiešām ceļo. Panāciet, lai mērījumu logs pārklājas ar stundām, kad rakstīšana ir lēna.

Izlasiet replikas stāvokli pirms kaut ko mainīt

Sāciet ar to, ko instances ziņo par sevi, jo abas puses var nesaskanēt par to, cik veselīga ir partnerība, un informācijas paneļa vidējais lielums slēpj, kura rinda kustas. Zemāk esošie vaicājumi atbild uz dažādiem jautājumiem: viens lasa replikācijas stāvokli pa datubāzēm, otrs lasa, kā konfigurēta katra replika. Izpildiet abus pirms pieskaraties režīmam.

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;

Pirmais rezultāts atdala žurnāla pārnesi no redo. log_send_queue_size augot, kamēr redo_queue_size paliek plakans, nozīmē, ka žurnāls nav ieradies; pretējais nozīmē, ka tas ir ieradies un atskaņošana atpaliek. Tikai pirmais gadījums atrodas commit ceļā.

Otrais rezultāts apstiprina, kuras replikas patiešām ir konfigurētas tā, kā jūs pieņemat, jo iepriekšējā incidenta laikā mainīts režīms mēdz palikt mainīts un nedokumentēts. Lasiet rindu, kas jums svarīga, nevis grupas noklusējumu: availability_mode_desc un failover_mode_desc ir katrai replikai. secondary_lag_seconds pastāv tikai SQL Server 2016 un jaunākās versijās, tāpēc vecāka versija jums atstāj tikai sūtīšanas rindas un redo kolonnas.

Pēc tam izmēriet reprezentatīvu rakstīšanu, nevis paļaujieties uz informācijas paneļa vidējo lielumu. Izpildiet zemāk esošo bloku pieejamības datubāzē, pēc tam izpildiet to vēlreiz pret to pašu tabulas formu datubāzē ārpus grupas tajā pašā instancē. Starpība starp abiem ilgumiem ir aptuvena attālinātā žurnāla cena, un strīdā ar tīkla komandu tā iztur daudz labāk nekā grafiks. Pēc tam mainiet vienu mainīgo vienlaikus, citādi starpība vairs neko nenozīmē.

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;

Ko pērk asinhronais commit un cik tas izmaksā

Ar asinhrono commit primārā replika pārstāj gaidīt attālinātā sacietējuma apstiprinājumu, tāpēc ceļš turp un atpakaļ pamet commit ceļu. Commit latence samazinās, un sekundārā var brīvi atpalikt tiktāl, cik neviens nekontrolē. Tā ir īsta gaidīšanas labošana un īsta solījuma maiņa.

Cena ir lēmums par atkopšanas punktu. Ja primārā replika mirst, pirms tās žurnāls sasniedz pārejas kļūmes gadījumā mērķi, kuru jūs patiešām varat izmantot, pakalpojuma pārvietošana uz asinhrono kopiju izmet transakcijas, kuras lietojumprogramma jau paziņojusi kā commit. Neviens konfigurācijas dialogs to tā nepasniedz, jo tas ir biznesa jautājums par pieņemamiem zaudējumiem, nevis veiktspējas iestatījums. Pierakstiet pieļaujamo zaudējumu logu pirms incidenta, nevis tā laikā.

Vienojieties par režīmu ar datu īpašnieku rakstiski, kopā ar pārejas kļūmes gadījumā procedūru tam gadījumam, kad vēlamais mērķis nav pieejams. Sinhronais projektēšanas dokumentā nav operatīvā rokasgrāmata, un asinhronais nav licence pārstāt uzraudzīt rindas.

Izvēlieties labojumu, ko vēlāk varēsiet aizstāvēt

Ir četras godīgas iespējas. Nogrieziet izvairāmus commit ceļus turp un atpakaļ tur, kur lietojumprogrammas semantika pieļauj pakešapstrādi; izlabojiet izmērīto pārneses vai krātuves šaurās vietas, kas var nozīmēt ātrāku žurnāla apjomu sekundārajā, nevis lielāku cauruli; pārvietojiet repliku tuvāk, lai ceļš turp un atpakaļ saruktu; vai mīkstiniet aizsardzības politiku un pieņemiet plašāku zaudējumu logu. Katra pērk latenci, iztērējot kaut ko citu, un ceturtā iztērē izturību. Nosauciet izdevumus pirms izvēles.

Izlemiet, vienlaikus acu priekšā turot darba slodzes latences mērķi un tās izturības prasību, jo viena optimizācija klusi iztērē otru. Pēc tam vēlreiz izpildiet to pašu transakciju, kuru izmērījāt pirms izmaiņām. Labojums, kas nevar pakustināt šo skaitli, ir minējums ar izmaiņu biļeti.

Saglabājiet pirms un pēc rādījumus izmaiņu ierakstā. Citādi nākamais cilvēks, kurš ierauga lēnu rakstīšanu, atkārto izmeklēšanu no sākuma un atkal sāk vainot tuneli.