Prečo vaše synchrónne potvrdenie SQL čaká na cestu VPN tam a späť

Latencia zápisu vyskočila po presune repliky na druhú lokalitu a tunel je najnovší komponent, takže nesie vinu. Tunel môže byť nevinný: v skupine dostupnosti so synchrónnym potvrdením primárna nemôže potvrdiť potvrdenie, kým sa nedokončí vzdialený zápis do denníka, takže každá transakcia platí cestu tam a späť, nech už spojenie prenesie akokoľvek megabitov. Priepustnosť meria bajty za sekundu, latencia meria, ako dlho trvá jedna výmena, a potvrdenie potrebuje na dokončenie len jednu malú výmenu. Jedno číslo rozhoduje spor: trvanie potvrdenia malej transakcie, merané v databáze dostupnosti a potom znova voči lokálnej tabuľke na tej istej inštancii.

Na čo primárna naozaj čaká

Pri synchrónnom potvrdení primárna zadržiava potvrdenie, kým partner nepotvrdí, že jeho záznamy v denníku sú zatvrdené. Zatvrdené znamená trvalo zapísané do transakčného denníka sekundárnej, nie prehrané do jej dátových stránok. Redo môže zaostávať minúty bez toho, aby pridal jedinú milisekundu k potvrdeniu primárnej.

Dokumentácia Microsoftu k režimom dostupnosti rozoberá to podanie ruky a opisuje, čo platforma robí, keď partner vypadne. Replika označená ako synchrónna je pravidlo o čakaní, nie trvalý sľub, že pre každé potvrdenie existuje zdravá vzdialená kópia. Odpojená cesta je definovaná samostatne a nie je to len to, že potvrdenie zlyhá.

Čakanie, ktoré pozorujete, je teda súčet: prenos denníka, plánovanie na oboch hostiteľoch a zápis do vzdialeného úložiska. Sekundárna s nasýteným objemom denníka pridáva čas, ktorý žiadny test rýchlosti neukáže. Ten disk sa meria zriedka, keď sťažnosť spomína VPN.

Priepustnosť nie je oneskorenie cesty tam a späť

Test rýchlosti krátko zaplaví cestu a oznámi rýchlosť. Potvrdenie žiada niečo užšie: ako dlho trvá malej správe dostať sa na druhú stranu, uložiť sa a vrátiť. Dĺžka cesty, fronty a strata paketov určujú to číslo a nič z toho sa nezlepší, keď poskytovateľ zdvihne strop.

„Rýchly“ tunel tak môže pridať viditeľnú pokutu záťaži náročnej na zápis zloženej z mnohých malých po sebe idúcich transakcií. Rovnaký celkový počet bajtov rozdelený na tisíc potvrdení platí cestu tam a späť tisíckrát; jeden hromadný prenos ju platí raz.

Požiadajte vlastníka siete o oneskorenie a straty merané priamo na trase repliky pri reprezentatívnej záťaži. Ping z kancelárskeho notebooku na VPN bránu alebo test rýchlosti na blízky uzol nepripisuje trase, po ktorej denník skutočne putuje, takmer nič. Zabezpečte, aby sa meracie okno prekrývalo s hodinami, keď je zápis pomalý.

Prečítajte stav repliky, než čokoľvek zmeníte

Začnite tým, čo inštancie hlásia o sebe, pretože obe strany sa môžu rozchádzať v tom, aké zdravé je partnerstvo, a priemer na paneli skrýva, ktorý front sa hýbe. Dotazy nižšie odpovedajú na rôzne otázky: jeden číta stav replikácie po databázach, druhý číta, ako je nakonfigurovaná každá replika. Spustite oba, než sa dotknete režimu.

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;

Prvý výsledok oddeľuje prenos denníka od redo. log_send_queue_size rastie, kým redo_queue_size stojí rovno, znamená, že denník neprišiel; opak znamená, že prišiel a prehrávanie zaostáva. Len prvý prípad sedí na ceste potvrdenia.

Druhý výsledok potvrdzuje, ktoré repliky sú skutočne nakonfigurované tak, ako predpokladáte, pretože režim zmenený počas skoršieho incidentu zvyčajne zostane zmenený a nedokumentovaný. Čítajte riadok, ktorý vás zaujíma, namiesto predvolenej hodnoty skupiny: availability_mode_desc a failover_mode_desc sú pre každú repliku. secondary_lag_seconds existuje len v SQL Server 2016 a novšom, takže staršia zostava vám nechá len stĺpce frontu odosielania a redo.

Potom zmerajte reprezentatívny zápis namiesto dôvery v priemer z panelu. Spustite blok nižšie v databáze dostupnosti a potom ho spustite znova voči rovnakému tvaru tabuľky v databáze mimo skupiny na tej istej inštancii. Rozdiel medzi oboma trvaniami je hrubá cena vzdialeného denníka a v diskusii so sieťovým tímom obstojí oveľa lepšie než graf. Potom meňte jednu premennú po druhej, inak rozdiel prestane niečo znamenať.

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;

Čo asynchrónne potvrdenie kupuje a čo stojí

Pri asynchrónnom potvrdení primárna prestane čakať na potvrdenie vzdialeného zatvrdenia, takže cesta tam a späť opustí cestu potvrdenia. Latencia potvrdenia klesne a sekundárna môže slobodne zaostávať o množstvo, ktoré nikto neriadi. To je skutočná oprava čakania a skutočná zmena sľubu.

Cena je rozhodnutie o bode obnovy. Ak primárna zomrie skôr, než sa jej denník dostane k cieľu prepnutia pri zlyhaní, ktorý skutočne môžete použiť, presun služby na asynchrónnu kópiu zahodí transakcie, ktoré aplikácia už ohlásila ako potvrdené. Žiadny konfiguračný dialóg to tak nepodáva, pretože je to obchodná otázka prijateľnej straty, nie nastavenie výkonu. Zapíšte tolerované okno straty pred incidentom, nie počas neho.

Dohodnite režim s vlastníkom dát písomne, spolu s postupom prepnutia pri zlyhaní pre prípad, keď preferovaný cieľ nie je dostupný. Synchrónne v návrhovom dokumente nie je prevádzková príručka a asynchrónne nie je licencia prestať sledovať fronty.

Vyberte opravu, ktorú neskôr obhájite

Existujú štyri poctivé možnosti. Odrežte zbytočné cesty potvrdenia tam a späť tam, kde to sémantika aplikácie dovoľuje dávkovaním; opravte zmerané úzke miesto prenosu alebo úložiska, čo môže znamenať rýchlejší objem denníka na sekundárnej namiesto väčšej rúry; priblížte repliku, aby sa cesta tam a späť skrátila; alebo uvoľnite ochrannú politiku a prijmite širšie okno straty. Každá kupuje latenciu tým, že minie niečo iné, a štvrtá minie trvanlivosť. Pomenujte výdavok, než vyberiete.

Rozhodujte sa s cieľom latencie záťaže a jej požiadavkou na trvanlivosť súčasne pred sebou, pretože optimalizácia jedného potichu míňa druhé. Potom znova spustite tú istú transakciu, ktorú ste zmerali pred zmenou. Oprava, ktorá nedokáže pohnúť týmto číslom, je dohad s tiketom zmeny.

Uchovajte odčítania pred a po v zázname zmeny. Inak ďalší človek, ktorý uvidí pomalé zápisy, zopakuje vyšetrovanie od začiatku a znova začne obviňovať tunel.