Proč rychlá VPN stále zpomaluje synchronní potvrzení v SQL

Otevřete relaci dotazu na primáru a podívejte se, na co čeká prostý zápis. Pokud databáze patří do skupiny dostupnosti se synchronním potvrzením a sekundár je připojený, část tohoto čekání opouští budovu: záznamy logu putují na repliku, jsou tam zpevněny a zpráva o tomto zpevnění se vrací dřív, než se potvrzení dokončí. Šířka pásma tuto cestu tam a zpět nezkracuje. Následující popis sleduje potvrzení z obrazovky na vzdálený disk a zpět.

Začněte u typu čekání na primáru

Zápis čekající na vzdálené replice se projeví jako čekání související s logem, nikoli jako čekání na procesor nebo zámek, a doba trvání transakce odpovídá cestě tam a zpět místo počtu řádků. Mnoho malých potvrzení to ukáže, protože každé platí cestu zvlášť. Jedna hromadná operace skrývá stejné náklady v jednom delším potvrzení.

Než cokoli usoudíte o lince, seřaďte zátěž podle četnosti potvrzení.

Přečtěte si stav repliky dřív, než začnete číst síť. Důležité čítače jsou fronta odesílání, fronta redo a stav synchronizace a společně ukazují, zda sekundár drží tempo, nebo zaostává. Rostoucí fronta odesílání ukazuje na přenos, kdežto rostoucí fronta redo na vlastní práci nebo úložiště sekundáru. To jsou různé opravy a ani jedné nepomůže přidání šířky pásma.

Sledujte potvrzení až k sekundáru

Při synchronním potvrzení primár čeká na potvrzení, že příslušný log byl zpevněn na sekundáru, než ohlásí potvrzení jako hotové. Zpevněno znamená trvale v logu, ne přehrané do datových stránek. Právě tento rozdíl vysvětluje, proč synchronní sekundár může zaostávat v redo, a přitom stále potvrzovat zpevnění.

Projděte cestu popořadě a měřte každou fázi místo celku. Záznamy logu jdou přes přenos, sekundár je zapisuje a vyrovnává a potvrzení se vrací stejnou cestou. Zpoždění přenosu, plánování sekundáru a latence logového disku sekundáru se všechny sčítají a jen první patří správci sítě. Sekundár, jehož objem logu je nasycen něčím jiným, může každé potvrzení prodloužit, zatímco linka stojí nečinně.

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;

Pořiďte takový snímek před reprezentativním zápisem a po něm, ne jednou za tiché odpoledne. Právě rozdíl vám řekne, která fronta se pohnula, zatímco potvrzení čekalo.

Měřte cestu, ne linku

Test propustnosti měří kapacitu mezi dvěma body, které nejsou vaše repliky, při zátěži, která není vaše práce. Požádejte správce sítě o zpoždění a ztráty po skutečné cestě repliky, zatímco běží skutečný provoz, v obou směrech. Ztráty tu rozhodují víc než kapacita, protože ztracený segment stojí přenos navíc a každé potvrzení čeká na jedno potvrzení. Linka, která vypadá výborně v testu stahování, může být pro upovídaný vzor potvrzení stále nevhodná.

Během měření zachovejte zabezpečení přenosu databáze a řízení přístupu nedotčené. Měření cesty není nikdy důvodem je obejít.

Propojte časy s čítači, ne s intuicí. Pokud fronta odesílání zůstává prázdná a potvrzení přesto čeká, zpoždění je v potvrzení nebo ve vyrovnání sekundáru. Pokud fronta odesílání trvale roste, omezujícím faktorem je přenos nebo kapacita. Zapište, které pozorování závěr podpořilo, aby další člověk mohl zopakovat měření místo hádky.

Co asynchronní režim skutečně mění

Asynchronní potvrzení odstraňuje čekání na potvrzení zpevnění od sekundáru, a proto jsou zápisy rychlejší a proto se mění vaše pozice trvalosti. Primár potvrdí transakci bez tohoto vzdáleného potvrzení. Sekundáru je pak dovoleno zaostávat a toto zaostávání je expozice.

Pokud se primár ztratí dřív, než log dosáhne použitelného cíle převzetí, vynucení služby na tuto repliku zahodí transakce, o kterých už aplikace dostala zprávu, že jsou potvrzené.

To je rozhodnutí o bodu obnovy a patří vlastníkovi databáze, ne kontrole výkonu. Nejprve nastavte tolerované okno ztráty dat, zvolte režim, který je splňuje, a teprve pak optimalizujte uvnitř této hranice. Možnosti, které zachovávají synchronní ochranu, zahrnují odstranění vyhnutelných cest potvrzení tam, kde to aplikace dovolí, opravu změřeného úzkého místa v přenosu nebo úložišti a přesun repliky, aby potvrzení urazilo menší vzdálenost. Važte je proti požadavku na trvalost, se kterým jste začali a který se nezměnil.