Защо синхронното ви SQL потвърждение чака двупосочното пътуване през VPN

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

За какво всъщност чака първичната

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

Документацията на Microsoft за режимите на наличност описва това ръкостискане и какво прави платформата, когато партньор отпадне. Реплика, отбелязана като синхронна, е правило за изчакване, а не постоянен обет, че за всяко потвърждение съществува здраво отдалечено копие. Прекъснатият път се дефинира отделно и той не е просто това, че потвърждението се проваля.

Следователно изчакването, което наблюдавате, е сбор: пренос на журнала, планиране на двата хоста и запис в отдалеченото хранилище. Вторична с наситен обем на журнала добавя време, което нито един тест за скорост няма да покаже. Този диск рядко се измерва, когато оплакването посочва VPN.

Пропускателната способност не е закъснение за двупосочно пътуване

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

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

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

Прочетете състоянието на репликата, преди да промените нещо

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

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;

Първият резултат отделя преноса на журнала от redo. log_send_queue_size расте, докато redo_queue_size стои плоско, означава, че журналът не е пристигнал; обратното означава, че е пристигнал и преиграването изостава. Само първият случай е на пътя на потвърждението.

Вторият резултат потвърждава кои реплики наистина са конфигурирани така, както предполагате, защото режим, променен по време на предишен инцидент, обикновено остава променен и недокументиран. Четете реда, който ви интересува, вместо груповата настройка по подразбиране: availability_mode_desc и failover_mode_desc са за всяка реплика. secondary_lag_seconds съществува само в SQL Server 2016 и по-нови, така че по-стара сборка ви оставя само колоните за опашката на изпращане и redo.

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

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;

Какво дава асинхронното потвърждение и какво струва

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

Цената е решение за точка на възстановяване. Ако първичната умре, преди журналът ѝ да достигне failover цел, която наистина можете да използвате, преместването на услугата към асинхронното копие изхвърля транзакции, които приложението вече е съобщило като потвърдени. Никой диалог за конфигурация не го представя така, защото това е бизнес въпрос за допустима загуба, а не настройка за производителност. Запишете допустимия прозорец на загуба преди инцидента, не по време на него.

Съгласувайте режима с този, който притежава данните, писмено, заедно с процедурата за failover за случая, когато предпочитаната цел е недостъпна. Синхронно в проектен документ не е оперативна инструкция, а асинхронно не е лиценз да спрете да следите опашките.

Изберете поправка, която можете да защитите после

Съществуват четири честни варианта. Отрежете избегнатите двупосочни пътувания за потвърждение, където семантиката на приложението позволява групиране; поправете измереното затруднение в преноса или хранилището, което може да означава по-бърз обем на журнала на вторичната, а не по-голяма тръба; приближете репликата, за да се свие двупосочното пътуване; или разхлабете политиката за защита и приемете по-широк прозорец на загуба. Всяка покупка на закъснение плаща с нещо друго, а четвъртата плаща с устойчивост. Назовете разхода, преди да изберете.

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

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