Чому швидкий VPN усе одно сповільнює синхронну фіксацію SQL

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

Почніть із типу очікування на основному сервері

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

Перш ніж робити будь-які висновки про канал, відсортуйте робоче навантаження за частотою фіксацій.

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

Простежте підтвердження до вторинної репліки

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

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

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;

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

Вимірюйте шлях, а не канал

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

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

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

Що насправді змінює асинхронний режим

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

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

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