Почему быстрый 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;

Сделайте такой снимок до и после показательной записи, а не один раз тихим днём. Именно разница показывает, какая очередь сдвинулась, пока фиксация ждала.

Измеряйте путь, а не канал

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

Сохраняйте безопасность транспорта базы данных и контроль доступа нетронутыми во время измерений. Измерение пути никогда не является поводом обходить их.

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

Что на самом деле меняет асинхронный режим

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

Если основной сервер потерян до того, как журнал достигнет пригодной цели переключения, принудительный перевод службы на эту реплику отбрасывает транзакции, о которых приложение уже получило сообщение как о зафиксированных.

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