Защо бърз VPN все още забавя синхронно фиксиране в SQL

Отворете сесия за заявка на първичния сървър и наблюдавайте какво чака едно просто записване. Ако базата данни е в група за достъпност със синхронно фиксиране и вторичният е свързан, част от това изчакване излиза извън сградата: записите в журнала пътуват до репликата, затвърждават се там и вестта за това затвърждаване се връща, преди фиксирането да приключи. Честотната лента не съкращава този двупосочен път. Описанието по-долу проследява потвърждението от екрана до отдалечения диск и обратно.

Започнете от типа изчакване на първичния

Записване, което чака на отдалечената реплика, се показва като изчакване, свързано с журнала, а не като изчакване на процесор или ключалка, и продължителността на транзакцията следва двупосочния път, а не броя редове. Многото малки фиксирания го правят очевидно, защото всяко плаща пътя отделно. Една масова операция скрива същата цена в едно по-дълго потвърждение.

Сортирайте натоварването по честота на фиксиранията, преди да правите какъвто и да е извод за връзката.

Прочетете състоянието на репликата, преди да четете мрежата. Броячите, които имат значение, са опашката за изпращане, опашката за повторно изпълнение и състоянието на синхронизация, и заедно те показват дали вторичният успява да настига, или изостава. Растящата опашка за изпращане сочи към транспорта, а растящата опашка за повторно изпълнение сочи към собствената работа или хранилище на вторичния. Това са различни поправки и нито една от тях не се подобрява с добавяне на честотна лента.

Проследете потвърждението до вторичния

При синхронно фиксиране първичният чака потвърждение, че съответният журнал е затвърден на вторичния, преди да отчете фиксирането като готово. Затвърден означава трайно записан в журнала, а не преигран в страници с данни. Именно това разграничение е причината синхронен вторичен да изостава по повторно изпълнение, докато продължава да потвърждава затвърждаване.

Извървете пътя по ред и измервайте всеки етап, а не целия. Записите в журнала минават през транспорта, вторичният ги записва и изтласква, а потвърждението се връща по същия път. Закъснението на транспорта, планирането на вторичния и латентността на журналния диск на вторичния всички влизат в общата сума и само първото принадлежи на собственика на мрежата. Вторичен, чийто обем на журнала е наситен от нещо друго, може да удължи всяко фиксиране, докато връзката стои без работа.

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;

Направете такава снимка преди и след представително записване, а не веднъж в тих следобед. Именно разликата показва коя опашка се е преместила, докато фиксирането е чакало.

Измерете пътя, а не връзката

Тестът за пропускателна способност измерва капацитет между две точки, които не са вашите реплики, под натоварване, което не е вашата работа. Поискайте от собственика на мрежата закъснение и загуби по истинския път на репликата, докато тече истински трафик, в двете посоки. Загубите тук са по-важни от капацитета, защото загубен сегмент струва повторно предаване и всяко фиксиране чака едно потвърждение. Връзка, която изглежда отлична в тест за изтегляне, може все още да е лоша за бъбрив модел на фиксиране.

Пазете сигурността на транспорта на базата данни и контрола на достъпа непокътнати, докато измервате. Измерването на път никога не е причина да ги заобикаляте.

Свържете времената с броячите, а не с интуицията. Ако опашката за изпращане остава празна и фиксирането все още чака, закъснението е в потвърждението или в изтласкването на вторичния. Ако опашката за изпращане расте постоянно, ограничението е транспортът или капацитетът. Запишете кое наблюдение е подкрепило извода, така че следващият човек да повтори измерването, вместо спора.

Какво всъщност променя асинхронният режим

Асинхронното фиксиране премахва изчакването за потвърждение на затвърждаването от вторичния, затова записванията стават по-бързи и затова позицията ви по трайност се променя. Първичният потвърждава транзакцията без това отдалечено потвърждение. Тогава на вторичния е позволено да изостава и това изоставане е излагането.

Ако първичният бъде загубен, преди журналът да достигне използваема цел за превключване, принудителното прехвърляне на услугата към тази реплика изхвърля транзакции, за които приложението вече е било уведомено, че са фиксирани.

Това е решение за точка на възстановяване и принадлежи на собственика на базата данни, а не на преглед на производителността. Първо задайте допустимия прозорец за загуба на данни, изберете режима, който го удовлетворява, после оптимизирайте в тази граница. Опциите, които запазват синхронна защита, включват премахване на избягваемите двупосочни пътувания на фиксирането там, където приложението позволява, отстраняване на измерено транспортно или складово тясно място и преместване на репликата, така че потвърждението да пътува по-малко разстояние. Претеглете ги срещу изискването за трайност, с което започнахте и което не се е променило.