De ce un VPN rapid încă încetinește o confirmare SQL sincronă

Deschideți o sesiune de interogare pe primar și urmăriți ce așteaptă o scriere simplă. Dacă baza de date aparține unui grup de disponibilitate cu confirmare sincronă și secundarul este conectat, o parte din acea așteptare părăsește clădirea: înregistrările din jurnal călătoresc la replică, sunt întărite acolo, iar vestea despre acea întărire se întoarce înainte ca confirmarea să se termine. Lățimea de bandă nu scurtează acel drum dus-întors. Parcursul de mai jos urmărește confirmarea de la ecran la discul îndepărtat și înapoi.

Începeți cu tipul de așteptare pe primar

O scriere care așteaptă pe replica îndepărtată apare ca o așteptare legată de jurnal, nu ca o așteptare de procesor sau de blocare, iar durata tranzacției urmează drumul dus-întors în locul numărului de rânduri. Multe confirmări mici fac asta evident, pentru că fiecare plătește drumul separat. O singură operațiune în masă ascunde același cost într-o confirmare mai lungă.

Sortați volumul de lucru după frecvența confirmărilor înainte de a trage vreo concluzie despre legătură.

Citiți starea replicii înainte de a citi rețeaua. Contoarele care contează sunt coada de trimitere, coada redo și starea de sincronizare, iar împreună arată dacă secundarul ține pasul sau rămâne în urmă. O coadă de trimitere crescătoare indică transportul, în timp ce o coadă redo crescătoare indică munca sau stocarea secundarului însuși. Sunt reparații diferite și niciuna nu se îmbunătățește prin adăugarea de lățime de bandă.

Urmăriți confirmarea până la secundar

La confirmarea sincronă, primarul așteaptă confirmarea că jurnalul respectiv a fost întărit pe secundar înainte de a raporta confirmarea ca terminată. Întărit înseamnă durabil în jurnal, nu redat în paginile de date. Exact această distincție explică de ce un secundar sincron poate rămâne în urmă la redo confirmând totuși întărirea.

Parcurgeți calea în ordine și măsurați fiecare etapă în locul întregului. Înregistrările din jurnal trec prin transport, secundarul le scrie și le golește, iar confirmarea se întoarce pe același drum. Întârzierea transportului, planificarea secundarului și latența discului de jurnal al secundarului intră toate în total, și doar prima aparține proprietarului rețelei. Un secundar al cărui volum de jurnal este saturat de altceva poate întinde fiecare confirmare în timp ce legătura stă inactivă.

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;

Faceți acel instantaneu înainte și după o scriere reprezentativă, nu o dată într-o după-amiază liniștită. Diferența este ce vă spune ce coadă s-a mișcat în timp ce confirmarea aștepta.

Măsurați calea, nu legătura

Un test de debit măsoară capacitatea între două puncte care nu sunt replicile dumneavoastră, sub o încărcare care nu este munca dumneavoastră. Cereți proprietarului rețelei întârzierea și pierderea de-a lungul căii reale a replicii în timp ce curge trafic real, în ambele direcții. Pierderea contează mai mult decât capacitatea aici, pentru că un segment pierdut costă o retransmisie și fiecare confirmare așteaptă o confirmare. O legătură care pare excelentă într-un test de descărcare poate fi totuși nepotrivită pentru un model de confirmări vorbăreț.

Păstrați intacte securitatea transportului bazei de date și controalele de acces în timp ce măsurați. Măsurarea unei căi nu este niciodată un motiv să le ocoliți.

Corelați timpii cu contoarele în loc de intuiție. Dacă coada de trimitere rămâne goală și confirmarea încă așteaptă, întârzierea este în confirmare sau în golirea secundarului. Dacă coada de trimitere crește constant, transportul sau capacitatea este constrângerea. Notați ce observație a susținut concluzia, ca următoarea persoană să poată repeta măsurătoarea, nu discuția.

Ce schimbă de fapt modul asincron

Confirmarea asincronă elimină așteptarea confirmării de întărire de la secundar, de aceea scrierile devin mai rapide și de aceea poziția dumneavoastră de durabilitate se schimbă. Primarul confirmă tranzacția fără acea confirmare îndepărtată. Secundarul are atunci voie să rămână în urmă, iar acea întârziere este expunerea.

Dacă primarul se pierde înainte ca jurnalul să atingă o țintă de preluare utilizabilă, forțarea serviciului pe acea replică aruncă tranzacții despre care aplicația fusese deja informată că sunt confirmate.

Este o decizie despre punctul de recuperare și aparține proprietarului bazei de date, nu unei revizuiri de performanță. Stabiliți mai întâi fereastra de pierdere de date tolerată, alegeți modul care o satisface, apoi optimizați în acea limită. Opțiunile care păstrează protecția sincronă includ eliminarea călătoriilor de confirmare evitabile acolo unde aplicația permite, repararea unui blocaj măsurat de transport sau stocare și mutarea replicii astfel încât confirmarea să parcurgă o distanță mai mică. Cântăriți-le față de cerința de durabilitate cu care ați început, care nu s-a schimbat.