Zašto brz VPN i dalje usporava sinhronu SQL potvrdu

Otvorite sesiju upita na primarnom i pogledajte na šta čeka jednostavno pisanje. Ako baza pripada grupi dostupnosti sa sinhronom potvrdom i sekundarni je povezan, dio tog čekanja napušta zgradu: zapisi dnevnika putuju do replike, tamo se očvršćuju, a vijest o tom očvršćivanju vraća se prije nego što se potvrda završi. Propusnost ne skraćuje taj put tamo i nazad. Prikaz ispod prati potvrdu od ekrana do udaljenog diska i natrag.

Počnite od tipa čekanja na primarnom

Pisanje koje čeka na udaljenoj replici pojavljuje se kao čekanje vezano za dnevnik, a ne kao čekanje procesora ili zaključavanja, i trajanje transakcije prati put tamo i nazad umjesto broja redova. Mnoge male potvrde to čine očitim, jer svaka plaća put zasebno. Jedna masovna operacija skriva isti trošak unutar jedne duže potvrde.

Sortirajte radno opterećenje po učestalosti potvrda prije nego što zaključite bilo šta o vezi.

Pročitajte stanje replike prije nego što pročitate mrežu. Brojači koji su važni jesu red za slanje, red za ponovno izvršavanje i stanje sinhronizacije, i zajedno pokazuju drži li sekundarni korak ili zaostaje. Rastući red za slanje upućuje na prijenos, dok rastući red za ponovno izvršavanje upućuje na vlastiti rad ili pohranu sekundarnog. To su različite popravke i nijedna se ne poboljšava dodavanjem propusnosti.

Pratite potvrdu do sekundarnog

Kod sinhrone potvrde primarni čeka potvrdu da je dotični dnevnik očvršćen na sekundarnom prije nego što prijavi da je potvrda gotova. Očvršćeno znači trajno u dnevniku, ne ponovno izvršeno u stranicama podataka. Upravo to razlikovanje objašnjava zašto sinhroni sekundarni može zaostajati u ponovnom izvršavanju dok još potvrđuje očvršćivanje.

Prođite put redom i mjerite svaku fazu, a ne cjelinu. Zapisi dnevnika idu preko prijenosa, sekundarni ih zapisuje i ispira, a potvrda se vraća istim putem. Kašnjenje prijenosa, raspoređivanje sekundarnog i latencija diska dnevnika sekundarnog svi ulaze u ukupno, a samo prvo pripada vlasniku mreže. Sekundarni čiji je obim dnevnika zasićen nečim drugim može rastegnuti svaku potvrdu dok veza stoji besposlena.

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;

Napravite taj snimak prije i poslije reprezentativnog pisanja, a ne jednom u tiho poslijepodne. Razlika je ono što vam kaže koji se red pomjerio dok je potvrda čekala.

Mjerite put, a ne vezu

Test propusnosti mjeri kapacitet između dvije točke koje nisu vaše replike, pod opterećenjem koje nije vaš radni zadatak. Zatražite od vlasnika mreže kašnjenje i gubitak duž stvarnog puta replike dok stvarni promet teče, u oba smjera. Gubitak je ovdje važniji od kapaciteta, jer izgubljeni segment košta ponovni prijenos i svaka potvrda čeka jedno priznanje. Veza koja izgleda izvrsno u testu preuzimanja još uvijek može biti loša za govorljiv obrazac potvrda.

Održite sigurnost prijenosa baze i kontrole pristupa netaknutima dok mjerite. Mjerenje puta nikada nije razlog da ih zaobiđete.

Povežite vremena s brojačima, a ne s intuicijom. Ako red za slanje ostane prazan i potvrda još čeka, kašnjenje je u priznanju ili u ispiranju sekundarnog. Ako red za slanje stalno raste, ograničenje su prijenos ili kapacitet. Zapišite koje je opažanje podržalo zaključak, da sljedeća osoba može ponoviti mjerenje umjesto raspravu.

Šta asinhroni režim zapravo mijenja

Asinhrona potvrda uklanja čekanje na priznanje očvršćivanja od sekundarnog, zato pisanja postaju brža i zato se vaš položaj trajnosti mijenja. Primarni potvrđuje transakciju bez tog udaljenog priznanja. Sekundarnom je tada dopušteno zaostajanje, a to zaostajanje je izloženost.

Ako se primarni izgubi prije nego dnevnik stigne do upotrebljivog cilja prebacivanja, prisilno prebacivanje usluge na tu repliku odbacuje transakcije za koje je aplikacija već bila obaviještena da su potvrđene.

To je odluka o točki oporavka i pripada vlasniku baze, a ne pregledu performansi. Prvo postavite dopušteni prozor gubitka podataka, odaberite način koji ga zadovoljava, zatim optimizirajte unutar te granice. Opcije koje zadržavaju sinhronu zaštitu uključuju uklanjanje izbježivih putovanja potvrde tamo i nazad gdje aplikacija to dopušta, ispravljanje izmjerenog uskog grla u prijenosu ili pohrani i premještanje replike da priznanje prevali manju udaljenost. Odvažite ih prema zahtjevu trajnosti s kojim ste počeli, a koji se nije promijenio.