База данных группы доступности зависла в режиме несинхронизации / ожидания восстановления

При обновлении хранилища в экземпляре SQL Server 2014 с пакетом обновления 1 (12.0.4422.0) мы столкнулись с проблемой, когда две базы данных не запускались на вторичном сервере после перезапуска SQL Server. Сервер был в автономном режиме в течение нескольких часов, пока мы устанавливали новые (более крупные) твердотельные накопители и копировали файлы данных на новый том. Когда мы перезапустили SQL Server, все базы данных, кроме двух, снова начали синхронизироваться. Два других были показаны в SSMS как не синхронизированные / ожидающие восстановления .

Если раньше у меня была похожая проблема « Не синхронизировать / восстановить» , я проверил состояние в разделе «Группы доступности» -> «Базы данных доступности», но они отображали красный X:

и даже при попытке приостановить перемещение данных выдается сообщение об ошибке:

Не удалось приостановить перемещение данных в базе данных «StackExchange.Bycycles.Meta», которая находится на реплике доступности «ny-sql03» в группе доступности «SENetwork_AG». (Microsoft.SqlServer.Smo)

Дополнительная информация: Возникла исключительная ситуация при выполнении оператора или пакета transact-SQL. (Microsoft.SqlServer.ConnectionInfo)

База данных «StackExchange.Bycycles.Meta» не может быть открыта из-за недоступных файлов или из-за недостатка памяти или дискового пространства. Подробности смотрите в журнале ошибок SQL Server. (Microsoft Sql Server, ошибка: 945)

Я проверил и файлы существовали и не было никаких проблем с разрешениями. Я также проверил журналы SQL Server в SSMS в разделе «Управление», но не увидел ничего относительно ожидающего восстановления или каких-либо проблем с двумя базами данных.

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

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

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

-- Remove database from Availability Group:    
Alter Database [StackExchange.Bicycles.Meta] SET HADR OFF;

-- Apply t-logs to catch up. This can be done manually in SSMS or via:
RESTORE LOG [StackExchange.Bicycles.Meta] FROM DISK = '\\ny-back01\backups\SQL\_Trans\SENetwork_AG\StackExchange.Bicycles.Meta\StackExchange.Bicycles.Meta_LOG_20160217_033201.trn' WITH NORECOVERY;

-- Re-join database to availability group
ALTER DATABASE [StackExchange.Bicycles.Meta] SET HADR AVAILABILITY GROUP = [SENetwork_AG];
ALTER DATABASE [StackExchange.Bicycles.Meta] SET HADR RESUME;

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

ОБНОВЛЕНИЕ: У нас была похожая проблема, когда после аварийного переключения AG вручную одна из баз данных на новой первичной реплике зависла в режиме « Не синхронизировать » ( после перезапуска SQL Server переключился на « Не синхронизируется / Ожидание восстановления» ), и вышеуказанные действия помогли устранить эту проблему. вопрос также.

Вы можете удалить БД из AAG, на основном узле сделать полное резервное копирование и резервное копирование транзакций, восстановить эти две резервные копии на БД вторичного узла, а затем снова добавить БД в AAG. В это время это может указывать на то, что DB вторичного узла не синхронизируется, а просто делает то, что было предложено во втором ответе (купите так, как он был оштрафован -2), я имею в виду перемещение вторичного узла на первичный, это исправит это.

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