Базы данных распределенной группы доступности SQL Server не синхронизируются после перезагрузки сервера

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

В прошлом месяце я обновил удаленный вторичный сервер с SQL Server 2016 до SQL Server 2017. Этот сервер является частью нескольких распределенных групп доступности (DAG) и отдельной группы доступности (AG) . Когда мы обновляли этот сервер, мы не знали, что он перейдет в нечитаемое состояние , поэтому в течение последнего месяца мы полагались исключительно на основной сервер.

В рамках предстоящего обновления я применил патч CU 4 к серверу и перезагрузил его. Когда сервер вернулся в рабочее состояние, только что исправленный вторичный сервер показал, что все группы DAG / AG синхронизировались без каких-либо проблем.

Тем не менее, основной показывал совсем другую историю. Сообщалось, что

• отдельный AG синхронизировался без каких-либо проблем
• но DAGs были в не Synchronzing / Не Здоровое состояние

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

• С основного я остановился и возобновил движение данных. Это не начало синхронизировать данные.
• На вторичном (тот, который я только что исправил) я запустил ALTER DATABASE [<database] SET HADR RESUME;- который выполняется без ошибок, но не возобновил синхронизацию

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

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

Я проверил и журнал ошибок SQL Server, и просмотрщик событий на вторичном сервере, ничего необычного, что я мог видеть, не было.

Обратите внимание, что это не окончательный ответ, но это лучший ответ после разговора с Тарын .

Тем не менее, основной показывал совсем другую историю. Он сообщал, что отдельный AG синхронизировался без каких-либо проблем, но группы доступности баз данных находились в состоянии Not Synchronizing / Not Healthy

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

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

• Проверьте sys.dm_hadr_database_replica_states на всех кластерах в поисках чего-либо, что не является здоровым. Если все показывает исправность, возможно, DMV еще не обновил
• Если это неработоспособно, проверьте журнал ошибок / DMV на наличие проблем с подключением (таких как невозможность подключения к серверу пересылки / глобальной первичной сети)
• В ответе Дэна упоминаются проблемы, которые могут возникнуть при запуске базы данных - хотя в этом случае экземпляр не может быть прочитан, так что, скорее всего, это не проблема, но может быть в вашем случае
• Если база данных читаема, тест на дым с использованием фиктивной таблицы / вставки или ...
• Расширенный сеанс событий с использованием элементов канала DEBUG sqlserver.hadr_dump_log_blockили sqlserver.hadr_apply_log_blockдля проверки, действительно ли вторичный сервер принимает / применяет блоки журнала или ...
• Объект Perfmon SQLServer:Database Replica\Log Bytes Received/sec

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

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

Я предвосхищу все это предупреждением о том, что у меня нет DAG в производстве. По сути, этот совет должен применяться как между AG, так и DAG.

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

Блокировка AG redo SPID

Как правило, происходит только на читаемом вторичном. Чтобы проверить, запустите следующее:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

Если появляются какие-либо блокирующие SPID, вам нужно будет их убить, прежде чем вторичный сервер сможет возобновить работу (именно DB STARTUPSPID обрабатывает операции повторного выполнения). Я бы посоветовал предварительно просмотреть блокирующий SPID, чтобы попытаться определить причину (обычно это длительный отчет).

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

Проверьте DMV

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

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

Статья BOL описывает suspend_reason немного дальше.

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

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

Улучшение: настройка значения SESSION_TIMEOUT для реплики распределенной группы доступности в SQL Server 2016 и 2017