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

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

Что такое отмена состояния?

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

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

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

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

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

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

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

Always On панели мониторинга сообщает о том, что на основном сервере не выполняется синхронизация

После отработки отказа группы доступности вы можете заметить, что дополнительный объект сообщается как не синхронизированный во время успешной отработки отказа. Панель мониторинга Always On сообщает о том, что на первичном объекте не выполняется синхронизация, а на вторичном — отмена.

Always On панели мониторинга сообщает о том, что на основном сервере не выполняется синхронизация	Always On отчеты о возврате панели мониторинга на вторичном сервере

Always On динамические административные административные представления не синхронизируются в основном

При запросе следующих Always On групп доступности (AG) динамических административных представлений (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". [CLIENT: <локальный компьютер>]

Эта ошибка также может быть зарегистрирована в журнале ошибок 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:D atabase Replica:Total Log Требуется отменить и SQL Server:D atabase Replica:Log Remaining для отмены и выберите базу данных группы доступности для экземпляра. В примере на следующем снимке экрана общий объем журнала, требующий отмены , отображается как 56,3 МБ, а журнал , оставшийся для отмены , медленно снижается до 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