Устранение неполадок базы данных группы доступности в состоянии восстановления

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

Что такое возврат состояния?

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

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

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

Если большая транзакция выполняется во время отработки отказа, новый журнал базы данных-получатель опережает базу данных-источник реплики. Новая общая точка восстановления, согласованная, потребует, чтобы вторичная реплика получала страницы из первичной реплики, чтобы она была в состоянии, где может возобновиться синхронизация. Обратный процесс также называется "Отмена повторного выполнения".

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

Симптомы и эффект базы данных группы доступности в обратном состоянии

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

Панель мониторинга AlwaysOn не синхронизируется с основной панелью мониторинга

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

Панель мониторинга AlwaysOn не синхронизируется с основной панелью мониторинга	Отчеты панели мониторинга AlwaysOn о возврате дополнительных данных

Динамические административные представления Always On сообщают НЕ СИНХРОНИЗАЦИЯ в основном

При запросе следующих групп доступности AlwaysOn (AGs) динамических административных представлений (DMV) базы данных находится в состоянии NOT SYNCHRONIZING .

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

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

Не удается получить доступ к базе данных-получателю только для чтения и отчетов.

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

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

Выполняется восстановление msg 922, level 14, State 1, Line 2 Database agdb. Дождитесь окончания восстановления.

Приложение, пытающееся войти в базу данных-получатель реплики в состоянии восстановления, не удается подключиться и вызывает ошибку 18456:

2023-01-26 13:01:13.100 Ошибка входа: 18456, серьезность: 14, состояние: 38. 2023-01-26 13:01:13.100 Вход в систему произошел сбоем для пользователя UserName<>. Причина. Не удалось открыть явно указанную базу данных agdb. [КЛИЕНТ: <локальный компьютер>]

Эта ошибка также может быть сообщена в журнале ошибок SQL Server, если не удалось выполнить аудит входа.

Оценка времени, оставшегося в состоянии восстановления

Используйте один из следующих методов, чтобы оценить время, оставшееся в обратном состоянии:

Использование сеанса XEvent AlwaysOn_health

Журнал диагностики расширенных событий AlwaysOn_health имеет событие hadr_trace_message , которое сообщает о том, что состояние выполняется каждые пять минут.

Подключитесь к вторичной реплике с помощью sql Server Management Studio (SSMS) обозреватель объектов и детализации управления, расширенных событий и сеансов. Щелкните правой кнопкой мыши событие AlwaysOn_health и выберите "Смотреть динамические данные". Вы должны получить новое окно табуляции, сообщая текущее состояние операции восстановления. Состояние сообщается каждые пять минут через hadr_trace_message событие, и сообщается полный процент операции восстановления.

Примечание.

Расширенное событие hadr_trace_message было добавлено в последние накопительные обновления в SQL Server 2019 и более поздних версий. Для наблюдения за этим расширенным событием в расширенном сеансе AlwaysOn_health событий необходимо запускать последние накопительные обновления.

Журнал ошибок SQL Server во вторичной реплике не очень помогает при оценке завершения восстановления. На следующем изображении можно наблюдать с 10:08 по 11:03 в режиме восстановления, мало сообщается. После получения всех страниц из первичной реплики вторичный объект теперь сможет откатить транзакцию, запущенную на исходном первичном объекте, который активировал восстановление состояния. Восстановление выполняется с 11:03 до 11:05. Вскоре после завершения восстановления база данных должна начать синхронизироваться с первичной репликой и выполнить все изменения, внесенные в первичной базе данных, в то время как база данных-получатель находилась в состоянии восстановления.

Мониторинг времени завершения с помощью Монитор производительности

Отслеживайте ход выполнения восстановления состояния с помощью счетчиков производительности SQL Server:Database Replica:Total Log, требующих отмены и SQL Server:Database Replica:Log, оставшихся для отмены, и выберите базу данных группы доступности для экземпляра. В примере на следующем снимке экрана общее количество журналов, требующих отмены, сообщается как 56,3 мб, а оставшиеся журналы для undo медленно удаляются до 0, что сообщает о ходе восстановления хода выполнения.

Каковы другие варианты, отличные от ожидания?

Корпорация Майкрософт рекомендует оценить время завершения восстановления состояния.

Добавление вторичной реплики к группе доступности

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

Внимание

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

Устранение отказа рабочих нагрузок только для чтения

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

Избегайте отмены состояния — мониторинг больших транзакций

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

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC