Чому ваша синхронна фіксація 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;

Що купує асинхронна фіксація і скільки вона коштує

За асинхронної фіксації основна репліка перестає чекати на підтвердження віддаленого загартування, тож поїздка туди й назад залишає шлях фіксації. Затримка фіксації падає, а вторинна може вільно відставати на величину, яку ніхто не контролює. Це справжнє виправлення очікування й справжня зміна обіцянки.

Ціна — рішення про точку відновлення. Якщо основна репліка помирає раніше, ніж її журнал дійде до цілі перемикання при збої, яку ви справді можете використати, перенесення служби на асинхронну копію відкидає транзакції, які застосунок уже повідомив як зафіксовані. Жодне вікно налаштувань не подає це так, бо це ділове питання про прийнятну втрату, а не параметр продуктивності. Запишіть припустиме вікно втрат до інциденту, а не під час нього.

Узгодьте режим із власником даних письмово, разом із процедурою перемикання при збої на випадок, коли бажана ціль недоступна. Синхронність у проєктному документі — не оперативна інструкція, а асинхронність — не ліцензія перестати стежити за чергами.

Виберіть виправлення, яке зможете захистити потім

Є чотири чесні варіанти. Відріжте уникнувані поїздки фіксації туди й назад там, де семантика застосунку дозволяє пакетування; виправте виміряне вузьке місце передавання або сховища, що може означати швидший обсяг журналу на вторинній замість більшої труби; наблизьте репліку, щоб поїздка скоротилася; або послабте політику захисту й прийміть ширше вікно втрат. Кожен купує затримку, витрачаючи щось інше, а четвертий витрачає довговічність. Назвіть витрату, перш ніж вибирати.

Вирішуйте, тримаючи перед собою одночасно ціль затримки навантаження та вимогу до його довговічності, бо оптимізація одного тихо витрачає інше. Потім знову виконайте ту саму транзакцію, яку виміряли до зміни. Виправлення, яке не може зрушити це число, — здогад із квитком на зміну.

Зберігайте показники до і після в записі про зміну. Інакше наступна людина, яка побачить повільний запис, повторить розслідування з початку і знову почне звинувачувати тунель.