Траблшутинг задержек AlwaysOn: устранение очередей REDO и Log Send Queue
Отставание вторичных реплик в группах доступности AlwaysOn проявляется следующими факторами:
- Огромный размер очереди Redo Queue Size или Log Send Queue Size в мониторинге SSMS AlwaysOn Dashboard;
- Увеличение RPO (риск потери данных) при переходе на резерв в асинхронном режиме;
- Задержки при чтении данных с вторичной реплики (Read-Only Routing возвращает устаревшую информацию);
- Рост времени фиксации транзакций (HADR_SYNC_COMMIT wait type) на первичной реплике.
1. Мониторинг задержек репликации через DMV
SELECT
ar.replica_server_name,
adc.database_name,
drs.is_local,
drs.is_primary_replica,
drs.synchronization_state_desc,
drs.log_send_queue_size AS LogSendQueue_KB,
drs.redo_queue_size AS RedoQueue_KB,
drs.redo_rate AS RedoRate_KB_sec,
drs.last_redone_time
FROM sys.dm_hadr_database_replica_states drs
JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id
JOIN sys.availability_databases_cluster adc ON drs.group_database_id = adc.group_database_id;2. Причины накопления очередей и их решение
Проблема А: Задержка передачи по сети (Log Send Queue)
- Узкий канал связи между ЦОД или насыщение сетевого адаптера;
- Включите сжатие сетевого трафика AlwaysOn Endpoint:
ALTER AVAILABILITY GROUP [AG_1C]
MODIFY REPLICA ON N'SQL-NODE2'
WITH (SESSION_TIMEOUT = 15);Проблема Б: Задержка применения лога на вторичном узле (Redo Queue)
Поток Redo на вторичной реплике упирается в дисковый ввод-вывод или блокируется параллельными Read-Only запросами пользователей.
3. Включение многопоточного применения лога (Parallel Redo)
В SQL Server 2016 и новее Parallel Redo включен по умолчанию. Если вторичный узел испытывает дефицит потоков worker threads, увеличьте пул потоков:
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'max worker threads', 1024;
RECONFIGURE;4. Устранение блокировок Redo-потока отчетами (Read-Only Queries)
На вторичной реплике тяжелые SELECT блокируют применение логов. Включите изоляцию моментальных снимков:
ALTER DATABASE [ERP_1C] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [ERP_1C] SET READ_COMMITTED_SNAPSHOT ON; Частые вопросы (FAQ)
Что такое Log Send Queue и Redo Queue?
Log Send Queue — это объем транзакций в КБ, который сформирован на мастере, но еще не передан по сети. Redo Queue — это объем транзакций, который уже принят вторичной репликой, записан в LDF, но еще не применен к страницам данных в файле MDF.
Почему при массовой переиндексации на мастере Redo Queue взлетает до гигабайтов?
Операции перестроения индексов генерируют колоссальный объем журнальных записей. Вторичная нода не успевает переписывать терабайты страниц данных. Выполняйте переиндексацию порционно или используйте Resumable Index Rebuild.
Как принудительно ускорить Redo поток?
Разнесите файлы MDF и LDF вторичной реплики на быстрые NVMe-накопители и исключите блокировки со стороны длительных аналитических отчетов.
Влияет ли Redo Queue на время переключения (Failover Time)?
Напрямую. При переключении вторичная нода не станет активной, пока полностью не обработает всю очередь Redo. Если очередь составляет 50 ГБ, переключение может затянуться на 10-20 минут.