Мы готовимся к значительному обновлению наших 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, и просмотрщик событий на вторичном сервере, ничего необычного, что я мог видеть, не было.