Устранение неполадок с очередью восстановления в группе доступности Always On

  • Статья

В этой статье содержатся сведения о решениях проблем, связанных с постановкой в очередь восстановления.

Что такое очередь восстановления?

Изменения, внесенные в основную реплика в базе данных группы доступности, отправляются во все вторичные реплики, определенные в одной группе доступности. После того как эти изменения поступят во вторичные реплики, они сначала записываются в файл журнала транзакций базы данных группы доступности. Затем Microsoft SQL Server использует операцию восстановления или повтора для обновления файлов базы данных.

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

Симптомы и последствия восстановления (повтор) постановки в очередь

Запрос первичной и вторичной реплики возвращает разные результаты

Рабочие нагрузки только для чтения, которые запрашивают вторичные реплики, могут запрашивать устаревшие данные. Если возникает очередь восстановления, изменения данных в базе данных-источнике реплика могут не отражаться в базе данных-получателе при запросе одинаковых данных.

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

Дополнительные сведения см. в разделе Задержка данных на дополнительных реплика раздела "Различия между режимами доступности для Always On группы доступности".

Время отработки отказа больше или превышено время RTO

Целевое время восстановления (RTO) — это максимальное время простоя базы данных, которое может справиться организация. RTO также описывает, как быстро организация может восстановить доступ к базе данных после сбоя. Если на вторичном реплика во время отработки отказа имеется значительная очередь восстановления, восстановление может занять больше времени. После восстановления база данных перейдет на роль-источник и будет представлять состояние базы данных, которая существовала до отработки отказа. Более длительное время восстановления может замедлить возобновление производства после отработки отказа.

Различные функции диагностики сообщают о очереди восстановления группы доступности

В случае постановки в очередь восстановления панель мониторинга Always On в SQL Server Management Studio (SSMS) может сообщать о неработоспособной группе доступности.

Как проверка для восстановления (повторной) очереди

Очередь восстановления — это измерение для каждой базы данных, которое можно проверить с помощью панели мониторинга Always On на первичном реплика или с помощью динамического административного представления (DMV) sys.dm_hadr_database_replica_states на основном или вторичном реплика. счетчики Монитор производительности проверка очереди восстановления и частоту восстановления. Эти счетчики должны быть проверены на соответствие вторичному реплика.

В следующих разделах приведены методы для активного мониторинга очереди восстановления базы данных группы доступности.

Sys.dm_hadr_database_replica_states запросов

Динамическое административное sys.dm_hadr_database_replica_states представление сообщает по строке для каждой базы данных группы доступности. Одним из столбцов в отчете является redo_queue_size. Это значение представляет собой размер очереди восстановления, измеряемый в килобайтах. Вы можете настроить запрос, аналогичный приведенному ниже, чтобы отслеживать любую тенденцию в размере очереди восстановления каждые 30 секунд. Запрос выполняется на основном реплика. Он использует is_local=0 предикат для передачи данных для вторичного реплика, где redo_queue_size и redo_rate являются актуальными.

WHILE 1=1
BEGIN
SELECT drcs.database_name, ars.role_desc, drs.redo_queue_size, drs.redo_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
waitfor delay '00:00:30'
END

Вот как выглядят выходные данные.

Снимок экрана: выходные данные запроса о данных для дополнительного реплика, где релевантны redo_queue_size и redo_rate.

Просмотр очереди восстановления на панели мониторинга Always On

Чтобы просмотреть очередь восстановления, выполните следующие действия.

  1. Откройте панель мониторинга Always On в SSMS, щелкнув правой кнопкой мыши группу доступности в обозреватель объектов SSMS.

  2. Выберите Показать панель мониторинга.

    Базы данных группы доступности перечислены последними, и в них отображаются некоторые данные. Хотя размер очереди повтора (КБ) и скорость повтора (КБ/с) по умолчанию не указаны, их можно добавить в это представление, как показано на снимке экрана на следующем шаге.

  3. Чтобы добавить эти счетчики, щелкните правой кнопкой мыши заголовок над отчетами базы данных и выберите из списка доступных столбцов.

  4. Чтобы добавить размер очереди повтора (КБ) и частоту повтора (КБ/с), щелкните правой кнопкой мыши заголовок, выделенный красным цветом на следующем снимке экрана.

    Снимок экрана, на котором показано добавление счетчиков Размер очереди повтора (КБ) и Скорость повтора (КБ/с).

    По умолчанию панель мониторинга Always On автоматически обновляет размер очереди повтора (КБ) и частоту повтора (КБ/с) каждые 60 секунд.

    Снимок экрана: счетчики обновления, для которых задано значение каждые 60 секунд.

Просмотр очереди восстановления в Монитор производительности

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

  1. Откройте Монитор производительности на дополнительном реплика.

  2. Нажмите кнопку Добавить (счетчик).

  3. В разделе Доступные счетчики выберите SQLServer:Database Replica, а затем — Очередь восстановления и Счетчики байтов в секунду .

  4. В списке Экземпляр выберите базу данных группы доступности, которую необходимо отслеживать для постановки в очередь восстановления.

  5. Нажмите кнопку Добавить>ОК.

    Вот как может выглядеть увеличение очереди восстановления.

    Снимок экрана: увеличение очереди восстановления.

Интерпретация значений очереди восстановления

В этом разделе объясняется, как интерпретировать значения, связанные с очередью восстановления, которые были определены в предыдущем разделе.

Когда возникает проблема с постановкой восстановления в очередь? Сколько следует выдержать в очереди восстановления?

Можно предположить, что если очередь восстановления сообщает значение 0, это означает, что очередь восстановления не выполняется во время создания этого отчета. Однако если ваша рабочая среда занята, следует ожидать, что очередь восстановления часто сообщает о значении, отличном от нуля, даже в работоспособной среде AlwaysOn. Во время обычной рабочей среды следует ожидать, что это значение будет колебаться в диапазоне от 0 до значения, отличного от нуля.

Если вы наблюдаете увеличение очереди восстановления с течением времени, требуется дальнейшее исследование. Это дополнительное действие указывает на то, что что-то изменилось. Если вы наблюдаете внезапный рост очереди восстановления, для устранения неполадок полезны следующие измерения:

  • Скорость повтора журнала (КБ/с) (панель мониторинга AlwaysOn)
  • Redo_rate в sys.dm_hadr_database_replica_states динамического административного представления

Получение базовых показателей для частоты повторов

Во время работоспособной производительности AlwaysOn отслеживайте частоту повторов в загруженных базах данных группы доступности. Как они выглядят в обычно занятое рабочее время? Каковы эти показатели в периоды обслуживания, когда крупные транзакции (перестроение индекса, процессы ETL) требуют более высокой пропускной способности транзакций в системе? Эти значения можно сравнить, наблюдая за ростом очереди восстановления, чтобы определить, что изменилось. Рабочая нагрузка может быть больше, чем обычно. Если частота повторов ниже, может потребоваться дальнейшее исследование, чтобы определить причину.

Тома рабочей нагрузки имеют значение

При наличии больших рабочих нагрузок (таких как инструкция UPDATE для миллиона строк, перестроение индекса в таблице размером 1 терабайт или даже пакет ETL, который вставляет миллионы строк), вы должны ожидать некоторого роста очереди восстановления сразу или с течением времени. Это ожидается, если в базу данных группы доступности в базу данных группы доступности будет внесено большое количество изменений.

Диагностика очередей восстановления (повтора)

Определив очередь восстановления для определенной базы данных группы доступности реплика, подключитесь к вторичной реплика, а затем запроситеsys.dm_exec_requests, чтобы определить wait_type и wait_time для потоков восстановления. Ниже приведен запрос, который может выполняться в цикле. Вы ищете высокую частоту одного или нескольких типов ожидания и даже время ожидания для этих типов. Ниже приведен пример запроса, который выполняется каждую секунду и сообщает о типах ожидания и времени ожидания для группы доступности "agdb":

WHILE (1=1)
BEGIN
SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')
waitfor delay '00:00:05.000'
END

Важно!

Для значимых выходных данных типа ожидания следует наблюдать увеличение очереди восстановления при использовании одного из описанных выше методов для мониторинга этого условия.

В этом примере сообщается о некоторых типах ожидания, связанных с операцией ввода-вывода (PAGEIOLATCH_UP, PAGEIOATCH_EX). Отслеживайте, чтобы проверка, имеют ли эти типы ожидания наибольшие wait_times значения, как указано в следующем столбце.

Снимок экрана: наибольшее время ожидания в следующем столбце.

SQL Server типы ожидания повтора

При определении типа ожидания ознакомьтесь со следующей статьей SQL Server 2016/2017 г. Дополнительные реплика группы доступности модели повтора и производительности. Microsoft Tech Community в качестве перекрестной ссылки на распространенные типы ожидания, вызывающие постановку в очередь восстановления, а также сведения об устранении проблемы.

Заблокированные потоки повтора на серверах-получателях отчетов

Если решение направляет отчеты (запросы) к базам данных группы доступности на вторичном реплика, эти запросы только для чтения получают блокировки стабильности схемы (Sch-S). Эти блокировки Sch-S могут блокировать получение потоков повтора изменений схемы (Sch-M) (также известных как "блокировки изменения схемы" или LCK_M_SCH_M) для внесения любых изменений языка определения данных (DDL), таких как ALTER TABLE или ALTER INDEX. Заблокированный поток повтора не может применять записи журнала, пока он не будет разблокирован. Это может привести к постановке в очередь восстановления.

Чтобы проверка исторические доказательства заблокированного повтора, откройте файлы трассировки AlwaysOn_health Xevent на вторичном реплика с помощью SSMS. Найдите lock_redo_blocked события.

Снимок экрана: проверка на наличие исторических доказательств заблокированного повтора.

Используйте Монитор производительности для активного отслеживания влияния заблокированного повтора на очередь восстановления. Добавьте счетчики SQL Server::D atabase Replica::Redo blocked/sec и SQL Server::D atabase Replica::Recovery Queue. На следующем снимок экрана показана ALTER TABLE ALTER COLUMN команда, которая выполняется для основного реплика, а длительный запрос выполняется к той же таблице на вторичном реплика. Счетчик повтора заблокирован/с указывает, что ALTER TABLE ALTER COLUMN команда выполнена. В то время как длительный запрос выполняется в той же таблице на вторичной реплика, любые последующие изменения в основном сервере вызовут увеличение очереди восстановления.

Снимок экрана: монитор для типа ожидания блокировки изменения схемы.

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

Снимок экрана: увеличение времени ожидания для LCK_M_SCH_M.

Однопотоковый повтор

SQL Server в Microsoft SQL Server 2016 впервые появилось параллельное восстановление баз данных-получателей реплика. Если при запуске SQL Microsoft Server 2012 или Microsoft SQL Server 2014 возникает очередь восстановления, можно выполнить обновление до более поздней версии программы, чтобы повысить производительность повтора в рабочей среде.

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

Чтобы определить, использует ли база данных группы доступности параллельное восстановление, подключитесь к дополнительному реплика и используйте следующий запрос, чтобы определить количество строк (потоков), которые применяют восстановление для базы данных группы доступности. В следующем примере, если база данных "agdb" является одним потоком, а ее команда — DB STARTUP, рабочая нагрузка восстановления может извлечь выгоду из параллельного восстановления.

SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN ('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')

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

Если вы убедитесь, что база данных использует однопоточный повтор, просмотрите описанный ранее алгоритм, чтобы определить, превышает ли SQL Server количество рабочих потоков в 100 рабочих потоков, выделенных для параллельного восстановления. Такое условие может быть причиной того, что база данных "agdb" использует только один поток для восстановления.

SQL Server 2022 г. теперь использует новый алгоритм параллельного восстановления, поэтому рабочие потоки назначаются для параллельного восстановления на основе рабочей нагрузки. Это устраняет вероятность того, что занятая база данных останется в однопотоковом восстановлении. Дополнительные сведения см. в разделе Использование потоков группами доступности раздела Предварительные требования, ограничения и рекомендации для Always On групп доступности.