Prečo rýchla VPN stále spomaľuje synchrónne potvrdenie v SQL

Otvorte reláciu dotazu na primári a pozrite sa, na čo čaká jednoduchý zápis. Ak databáza patrí do skupiny dostupnosti so synchrónnym potvrdením a sekundár je pripojený, časť tohto čakania opúšťa budovu: záznamy logu putujú na repliku, sú tam spevnené a správa o tomto spevnení sa vracia skôr, než sa potvrdenie dokončí. Šírka pásma túto cestu tam a späť neskracuje. Nasledujúci prehľad sleduje potvrdenie z obrazovky na vzdialený disk a späť.

Začnite pri type čakania na primári

Zápis čakajúci na vzdialenej replike sa prejaví ako čakanie súvisiace s logom, nie ako čakanie na procesor alebo zámok, a trvanie transakcie sleduje cestu tam a späť namiesto počtu riadkov. Mnohé malé potvrdenia to ukážu, pretože každé platí cestu zvlášť. Jedna hromadná operácia skryje rovnaké náklady v jednom dlhšom potvrdení.

Než čokoľvek usúdite o linke, zoraďte záťaž podľa frekvencie potvrdení.

Prečítajte si stav repliky skôr, než začnete čítať sieť. Dôležité počítadlá sú fronta odosielania, fronta redo a stav synchronizácie a spolu ukazujú, či sekundár drží tempo alebo zaostáva. Rastúca fronta odosielania ukazuje na prenos, kým rastúca fronta redo na vlastnú prácu alebo úložisko sekundára. To sú rôzne opravy a ani jednej nepomôže pridanie šírky pásma.

Sledujte potvrdenie až k sekundáru

Pri synchrónnom potvrdení primár čaká na potvrdenie, že príslušný log bol spevnený na sekundári, než ohlási potvrdenie ako hotové. Spevnené znamená trvalé v logu, nie prehrané do dátových stránok. Práve tento rozdiel vysvetľuje, prečo synchrónny sekundár môže zaostávať v redo a pritom stále potvrdzovať spevnenie.

Prejdite cestu poporiadku a merajte každú fázu namiesto celku. Záznamy logu idú cez prenos, sekundár ich zapisuje a vyrovnáva a potvrdenie sa vracia tou istou cestou. Oneskorenie prenosu, plánovanie sekundára a latencia logového disku sekundára sa všetky sčítajú a iba prvé patrí správcovi siete. Sekundár, ktorého objem logu je nasýtený niečím iným, môže každé potvrdenie natiahnuť, kým linka stojí nečinne.

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;

Urobte taký snímok pred reprezentatívnym zápisom a po ňom, nie raz za tiché popoludnie. Práve rozdiel vám povie, ktorá fronta sa pohla, kým potvrdenie čakalo.

Merajte cestu, nie linku

Test priepustnosti meria kapacitu medzi dvoma bodmi, ktoré nie sú vaše repliky, pri záťaži, ktorá nie je vaša práca. Požiadajte správcu siete o oneskorenie a straty po skutočnej ceste repliky, kým beží skutočná prevádzka, v oboch smeroch. Straty tu rozhodujú viac než kapacita, pretože stratený segment stojí opätovný prenos a každé potvrdenie čaká na jedno potvrdenie. Linka, ktorá vyzerá výborne v teste sťahovania, môže byť pre zhovorčivý vzor potvrdení stále nevhodná.

Počas merania zachovajte zabezpečenie prenosu databázy a riadenie prístupu nedotknuté. Meranie cesty nie je nikdy dôvodom ich obchádzať.

Spojte časy s počítadlami, nie s intuíciou. Ak fronta odosielania zostáva prázdna a potvrdenie ešte čaká, oneskorenie je v potvrdení alebo vo vyrovnaní sekundára. Ak fronta odosielania trvalo rastie, obmedzením je prenos alebo kapacita. Zapíšte, ktoré pozorovanie záver podporilo, aby ďalší človek mohol zopakovať meranie namiesto hádky.

Čo asynchrónny režim skutočne mení

Asynchrónne potvrdenie odstraňuje čakanie na potvrdenie spevnenia od sekundára, a preto sú zápisy rýchlejšie a preto sa mení vaša pozícia trvácnosti. Primár potvrdí transakciu bez tohto vzdialeného potvrdenia. Sekundáru je potom dovolené zaostávať a toto zaostávanie je vystavenie.

Ak sa primár stratí skôr, než log dosiahne použiteľný cieľ prevzatia, vynútenie služby na túto repliku zahodí transakcie, o ktorých už aplikácia dostala správu, že sú potvrdené.

To je rozhodnutie o bode obnovy a patrí vlastníkovi databázy, nie kontrole výkonu. Najprv nastavte tolerované okno straty dát, vyberte režim, ktorý ho spĺňa, a až potom optimalizujte v tejto hranici. Možnosti, ktoré zachovávajú synchrónnu ochranu, zahŕňajú odstránenie vyhnuteľných ciest potvrdenia tam, kde to aplikácia dovolí, opravu nameraného úzkeho miesta v prenose alebo úložisku a presun repliky, aby potvrdenie prešlo menšiu vzdialenosť. Zvážte ich proti požiadavke na trvácnosť, s ktorou ste začali a ktorá sa nezmenila.