Proč vaše synchronní potvrzení SQL čeká na obrátku přes VPN

Latence zápisu vyskočila poté, co se replika přesunula na druhé pracoviště, a tunel je nejnovější součást, takže nese vinu. Tunel může být nevinný: uvnitř skupiny dostupnosti se synchronním potvrzením nemůže primární potvrdit transakci, dokud není dokončen vzdálený zápis do protokolu, takže každá transakce platí cestu tam a zpět, ať už spojení přenese jakkoli megabitů. Propustnost měří bajty za sekundu, latence měří, jak dlouho trvá jedna výměna, a potvrzení potřebuje k dokončení jen jednu malou výměnu. Jeden údaj spor rozhodne: doba potvrzení malé transakce, měřená uvnitř databáze dostupnosti a znovu proti místní tabulce na stejné instanci.

Na co primární skutečně čeká

Při synchronním potvrzení primární drží potvrzení, dokud partner nepotvrdí, že jeho záznamy v protokolu jsou zatvrzené. Zatvrzené znamená trvale zapsané do transakčního protokolu sekundární, ne přehrané do jejích datových stránek. Redo může zaostávat minuty, aniž by k potvrzení primární přidalo jedinou milisekundu.

Dokumentace Microsoftu k režimům dostupnosti popisuje toto podání ruky a co platforma dělá, když partner vypadne. Replika označená jako synchronní je pravidlo o čekání, ne trvalý slib, že pro každé potvrzení existuje zdravá vzdálená kopie. Odpojená cesta je definována samostatně a není to prostě to, že potvrzení selže.

Čekání, které pozorujete, je tedy součet: přenos protokolu, plánování na obou hostitelích a zápis do vzdáleného úložiště. Sekundární s nasyceným objemem protokolu přidává čas, který žádný test rychlosti neukáže. Ten disk se měří zřídka, když stížnost jmenuje VPN.

Propustnost není zpoždění obrátky

Test rychlosti krátce zaplaví cestu a oznámí rychlost. Potvrzení se ptá na něco užšího: jak dlouho trvá malé zprávě, než dorazí na druhou stranu, uloží se a vrátí. Délka cesty, fronty a ztráta paketů určují tento údaj a nic z toho se nezlepší, když poskytovatel zvedne strop.

„Rychlý“ tunel tak může přidat viditelnou pokutu zátěži náročné na zápis složené z mnoha malých po sobě jdoucích transakcí. Stejný celkový počet bajtů rozdělený na tisíc potvrzení platí cestu tam a zpět tisíckrát; jeden hromadný přenos ji platí jednou.

Požádejte vlastníka sítě o zpoždění a ztrátovost měřené přímo na trase repliky při reprezentativní zátěži. Ping z kancelářského notebooku na VPN bránu nebo test rychlosti na blízký uzel nepřičítá trase, po níž protokol skutečně putuje, téměř nic. Zařiďte, aby se měřicí okno překrývalo s hodinami, kdy je zápis pomalý.

Přečtěte stav repliky, než cokoli změníte

Začněte tím, co instance hlásí o sobě, protože obě strany se mohou rozcházet v tom, jak zdravé partnerství je, a průměr na panelu skrývá, která fronta se hýbe. Dotazy níže odpovídají na různé otázky: jeden čte stav replikace po databázích, druhý čte, jak je každá replika nakonfigurována. Spusťte oba, než sáhnete na 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;

První výsledek odděluje přenos protokolu od redo. log_send_queue_size roste, zatímco redo_queue_size stojí rovně, znamená, že protokol nedorazil; opak znamená, že dorazil a přehrávání zaostává. Jen první případ sedí na cestě potvrzení.

Druhý výsledek potvrzuje, které repliky jsou skutečně nakonfigurovány tak, jak předpokládáte, protože režim změněný během dřívějšího incidentu obvykle zůstane změněný a nedokumentovaný. Čtěte řádek, který vás zajímá, místo výchozí hodnoty skupiny: availability_mode_desc a failover_mode_desc jsou pro každou repliku. secondary_lag_seconds existuje jen v SQL Server 2016 a novějším, takže starší build vám nechá jen sloupce fronty odesílání a redo.

Pak změřte reprezentativní zápis místo důvěry v průměr z panelu. Spusťte blok níže v databázi dostupnosti a potom ho znovu spusťte proti stejnému tvaru tabulky v databázi mimo skupinu na stejné instanci. Rozdíl mezi oběma dobami je hrubá cena vzdáleného protokolu a v diskusi se síťovým týmem obstojí mnohem lépe než graf. Potom měňte jednu proměnnou po druhé, jinak rozdíl přestane něco znamenat.

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;

Co asynchronní potvrzení kupuje a co stojí

U asynchronního potvrzení primární přestane čekat na potvrzení vzdáleného zatvrzení, takže cesta tam a zpět opustí cestu potvrzení. Latence potvrzení klesne a sekundární může zaostávat o množství, které nikdo neřídí. To je skutečná oprava čekání a skutečná změna slibu.

Cena je rozhodnutí o bodu obnovy. Pokud primární zemře dřív, než se její protokol dostane k cíli failoveru, který skutečně můžete použít, přesun služby na asynchronní kopii zahodí transakce, které aplikace už ohlásila jako potvrzené. Žádný konfigurační dialog to tak nepodává, protože je to obchodní otázka přijatelné ztráty, ne nastavení výkonu. Zapište tolerované okno ztráty před incidentem, ne během něj.

Dohodněte režim s tím, kdo vlastní data, písemně, spolu s postupem failoveru pro případ, kdy je preferovaný cíl nedostupný. Synchronní v návrhovém dokumentu není provozní příručka a asynchronní není licence přestat sledovat fronty.

Vyberte opravu, kterou později obhájíte

Existují čtyři poctivé možnosti. Odřízněte zbytečné obrátky potvrzení tam, kde to sémantika aplikace dovoluje dávkováním; opravte změřené úzké hrdlo přenosu nebo úložiště, což může znamenat rychlejší objem protokolu na sekundární místo větší trubky; přibližte repliku, aby se cesta tam a zpět zkrátila; nebo uvolněte ochrannou politiku a přijměte širší okno ztráty. Každá kupuje latenci tím, že utratí něco jiného, a čtvrtá utratí trvanlivost. Pojmenujte útratu, než vyberete.

Rozhodujte se s cílem latence zátěže a požadavkem trvanlivosti současně před sebou, protože optimalizace jednoho tiše utrácí druhé. Potom znovu spusťte stejnou transakci, kterou jste změřili před změnou. Oprava, která tím údajem nepohne, je dohad s tiketem změny.

Uchovejte odečty před a po v záznamu změny. Jinak další člověk, který uvidí pomalé zápisy, zopakuje vyšetřování od začátku a začne znovu obviňovat tunel.