Zakaj hitra VPN še vedno upočasnjuje sinhrono potrditev v SQL

Odprite sejo poizvedbe na primarnem in poglejte, kaj čaka preprost vpis. Če baza pripada skupini razpoložljivosti s sinhrono potrditvijo in je sekundarni povezan, del tega čakanja zapusti stavbo: zapisi dnevnika potujejo do replike, tam se utrdijo, in novica o tej utrditvi se vrne, preden se potrditev konča. Pasovna širina te poti tja in nazaj ne skrajša. Spodnji pregled sledi potrditvi z zaslona na oddaljeni disk in nazaj.

Začnite pri vrsti čakanja na primarnem

Vpis, ki čaka na oddaljeni repliki, se pokaže kot čakanje, povezano z dnevnikom, in ne kot čakanje procesorja ali zaklepa, trajanje transakcije pa sledi poti tja in nazaj namesto številu vrstic. Veliko majhnih potrditev to naredi očitno, ker vsaka plača pot zase. Ena množična operacija skrije enake stroške v eni daljši potrditvi.

Preden karkoli sklepate o povezavi, razvrstite delovno obremenitev po pogostosti potrditev.

Preberite stanje replike, preden preberete omrežje. Pomembni števci so čakalna vrsta pošiljanja, čakalna vrsta redo in stanje sinhronizacije, in skupaj kažejo, ali sekundarni dohaja ali zaostaja. Rastoča čakalna vrsta pošiljanja kaže na prenos, medtem ko rastoča čakalna vrsta redo kaže na lastno delo ali shrambo sekundarnega. To sta različni popravili in nobena se ne izboljša z dodajanjem pasovne širine.

Sledite potrditvi do sekundarnega

Pri sinhroni potrditvi primarni čaka na potrditev, da je bil zadevni dnevnik utrjen na sekundarnem, preden sporoči, da je potrditev končana. Utrjeno pomeni trajno v dnevniku, ne predvajano v podatkovne strani. Prav ta razlika pojasnjuje, zakaj sinhroni sekundarni lahko zaostaja pri redo, medtem ko še vedno potrjuje utrjevanje.

Prehodite pot po vrsti in merite vsako stopnjo namesto celote. Zapisi dnevnika gredo skozi prenos, sekundarni jih zapiše in izplakne, potrditev pa se vrne po isti poti. Zamuda prenosa, razporejanje sekundarnega in latenca njegovega dnevniškega diska vse pristanejo v skupnem seštevku, in samo prva pripada lastniku omrežja. Sekundarni, katerega obseg dnevnika je nasičen z nečim drugim, lahko raztegne vsako potrditev, medtem ko povezava stoji brez dela.

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;

Naredite tak posnetek pred reprezentativnim vpisom in po njem, ne enkrat na tiho popoldne. Razlika je tisto, kar vam pove, katera čakalna vrsta se je premaknila, medtem ko je potrditev čakala.

Merite pot, ne povezave

Preizkus prepustnosti meri zmogljivost med dvema točkama, ki nista vaši repliki, pod obremenitvijo, ki ni vaše delo. Prosite lastnika omrežja za zakasnitev in izgubo vzdolž prave poti replike, medtem ko teče pravi promet, v obe smeri. Izguba tu šteje več kot zmogljivost, ker izgubljen segment stane ponovni prenos in vsaka potrditev čaka eno potrditev. Povezava, ki je v preizkusu prenašanja videti odlična, lahko še vedno slabo ustreza zgovornemu vzorcu potrditev.

Med merjenjem ohranite varnost prenosa baze in nadzor dostopa nedotaknjena. Merjenje poti nikoli ni razlog za njuno obhajanje.

Povežite čase s števci, ne z intuicijo. Če čakalna vrsta pošiljanja ostane prazna in potrditev še vedno čaka, je zamuda v potrditvi ali v izplakovanju sekundarnega. Če čakalna vrsta pošiljanja vztrajno raste, sta omejitev prenos ali zmogljivost. Zapišite, katero opažanje je podprlo sklep, da bo naslednja oseba lahko ponovila meritev in ne razpravo.

Kaj asinhroni način resnično spremeni

Asinhrona potrditev odpravi čakanje na potrditev utrjevanja s sekundarnega, zato so vpisi hitrejši in zato se spremeni vaš položaj trajnosti. Primarni potrdi transakcijo brez te oddaljene potrditve. Sekundarnemu je nato dovoljeno zaostajati in ta zaostanek je izpostavljenost.

Če se primarni izgubi, preden dnevnik doseže uporabljiv cilj preklopa, vsiljeni prenos storitve na to repliko zavrže transakcije, za katere je aplikacija že bila obveščena, da so potrjene.

To je odločitev o obnovitveni točki in pripada lastniku baze, ne pregledu zmogljivosti. Najprej nastavite tolerirano okno izgube podatkov, izberite način, ki ga izpolnjuje, in nato optimizirajte znotraj te meje. Možnosti, ki ohranijo sinhrono zaščito, vključujejo odstranitev izogibnih poti potrditve tam, kjer aplikacija to dovoli, odpravo izmerjenega ozkega grla v prenosu ali shrambi, in premik replike, da potrditev prepotuje manjšo razdaljo. Pretehtajte jih proti zahtevi po trajnosti, s katero ste začeli in ki se ni spremenila.