Zašto vaša sinhrona SQL potvrda čeka povratno putovanje kroz VPN

Latencija pisanja je skočila nakon što je replika premještena na drugu lokaciju, a tunel je najnovija komponenta, pa on snosi krivicu. Tunel može biti nevin: unutar grupe dostupnosti sa sinhronom potvrdom primarna ne može priznati potvrdu dok se ne završi upis u udaljeni dnevnik, pa svaka transakcija plaća povratno putovanje koliko god megabita veza mogla prenijeti. Propusnost mjeri bajtove u sekundi, latencija mjeri koliko traje jedna razmjena, a potvrdi treba samo jedna mala razmjena da završi. Jedan broj rješava raspravu: trajanje potvrde male transakcije, mjereno unutar baze dostupnosti i ponovo prema lokalnoj tabeli na istoj instanci.

Šta primarna zapravo čeka

Pod sinhronom potvrdom primarna drži potvrdu dok partner ne potvrdi da su njegovi zapisi u dnevniku očvrsnuti. Očvrsnuto znači trajno zapisano u dnevnik transakcija sekundarne, a ne ponovno izvršeno u njenim stranicama podataka. Redo može zaostajati minutama bez dodavanja i jedne milisekunde potvrdi primarne.

Microsoftova dokumentacija o režimima dostupnosti objašnjava taj stisak ruke i opisuje šta platforma radi kada partner ispadne. Replika označena kao sinhrona je pravilo o čekanju, a ne trajno obećanje da za svaku potvrdu postoji zdrava udaljena kopija. Prekinuta putanja definiše se odvojeno i nije samo to da potvrda ne uspije.

Dakle, čekanje koje vidite je zbir: prijenos dnevnika, raspoređivanje na oba hosta i upis u udaljeno skladište. Sekundarna sa zasićenim volumenom dnevnika dodaje vrijeme koje nijedan test brzine neće pokazati. Taj disk se rijetko mjeri kada se u pritužbi spomene VPN.

Propusnost nije kašnjenje povratnog putovanja

Test brzine nakratko preplavi putanju i izvijesti o brzini. Potvrda traži nešto uže: koliko vremena treba maloj poruci da stigne na drugu stranu, bude sačuvana i vrati se. Dužina putanje, čekanje u redovima i gubitak paketa određuju taj broj i nijedno od toga se ne popravlja kada provajder podigne plafon.

Zato «brz» tunel može dodati vidljivu kaznu radnom opterećenju sklonom pisanju sastavljenom od mnogo malih uzastopnih transakcija. Isti ukupan broj bajtova podijeljen na hiljadu potvrda plaća povratno putovanje hiljadu puta; jedan skupni prijenos plaća ga jednom.

Zatražite od vlasnika mreže kašnjenje i gubitke mjerene na samoj ruti replike pod reprezentativnim opterećenjem. Ping s uredskog laptopa do VPN pristupnika ili test brzine do obližnjeg čvora gotovo ništa ne pripisuje ruti kojom dnevnik zaista putuje. Neka se mjerni prozor preklapa sa satima kada je pisanje sporo.

Pročitajte stanje replike prije nego što bilo šta promijenite

Počnite od onoga što instance izvještavaju o sebi, jer se dvije strane mogu ne složiti o tome koliko je partnerstvo zdravo i prosjek na nadzornoj ploči skriva koji se red pomiče. Upiti ispod odgovaraju na različita pitanja: jedan čita stanje replikacije po bazi, drugi čita kako je svaka replika konfigurisana. Pokrenite oba prije nego što dirnete režim.

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;

Prvi rezultat odvaja prijenos dnevnika od redoa. log_send_queue_size raste dok redo_queue_size stoji ravno znači da dnevnik nije stigao; obrnuto znači da je stigao i da reprodukcija zaostaje. Samo prvi slučaj sjedi na putu potvrde.

Drugi rezultat potvrđuje koje su replike zaista konfigurisane kako pretpostavljate, jer režim promijenjen tokom ranijeg incidenta obično ostaje promijenjen i nedokumentovan. Čitajte red koji vas zanima umjesto grupnog podrazumijevanog: availability_mode_desc i failover_mode_desc su po replici. secondary_lag_seconds postoji samo na SQL Server 2016 i novijim, pa vam starija verzija ostavlja samo kolone reda za slanje i redo.

Zatim mjerite reprezentativno pisanje umjesto da vjerujete prosjeku s nadzorne ploče. Pokrenite blok ispod u bazi dostupnosti, a zatim ga ponovo pokrenite prema istom obliku tabele u bazi izvan grupe na istoj instanci. Razlika između ta dva trajanja je gruba cijena udaljenog dnevnika i u raspravi s mrežnim timom drži se mnogo bolje od grafikona. Nakon toga mijenjajte jednu varijablu po jednu, inače razlika gubi smisao.

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;

Šta asinhrona potvrda kupuje i koliko košta

Uz asinhronu potvrdu primarna prestaje čekati potvrdu udaljenog očvršćivanja, pa povratno putovanje napušta put potvrde. Latencija potvrde pada i sekundarna je slobodna zaostajati za količinu koju niko ne kontroliše. To je stvarna popravka čekanja i stvarna promjena obećanja.

Cijena je odluka o tački oporavka. Ako primarna umre prije nego njen dnevnik stigne do failover cilja koji zaista možete koristiti, prebacivanje usluge na asinhronu kopiju odbacuje transakcije koje je aplikacija već prijavila kao potvrđene. Nijedan dijalog za konfiguraciju to tako ne predstavlja, jer je to poslovno pitanje o prihvatljivom gubitku, a ne postavka performansi. Zapišite tolerisani prozor gubitka prije incidenta, ne tokom njega.

Dogovorite režim s onim ko posjeduje podatke, pismeno, uz proceduru failovera za slučaj kada je željeni cilj nedostupan. Sinhrono u projektnom dokumentu nije operativna uputa, a asinhrono nije licenca da prestanete pratiti redove.

Izaberite popravku koju možete braniti kasnije

Postoje četiri iskrene opcije. Odrežite izbježiva povratna putovanja potvrde gdje semantika aplikacije dopušta grupisanje; popravite usko grlo u prijenosu ili skladištu koje ste izmjerili, što može značiti brži volumen dnevnika na sekundarnoj umjesto veće cijevi; približite repliku da se povratno putovanje smanji; ili ublažite zaštitnu politiku i prihvatite širi prozor gubitka. Svaka kupuje latenciju trošeći nešto drugo, a četvrta troši trajnost. Imenujte trošak prije nego što izaberete.

Odlucite s ciljem latencije radnog opterećenja i zahtjevom za trajnost istovremeno pred sobom, jer optimizacija jednog tiho troši drugo. Zatim ponovo pokrenite istu transakciju koju ste izmjerili prije promjene. Popravka koja ne može pomjeriti taj broj je nagađanje s kartom promjene.

Čuvajte očitanja prije i poslije u zapisu promjene. Inače sljedeća osoba koja vidi sporo pisanje ponavlja istragu od početka i opet počinje kriviti tunel.