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

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

 SSMS Not Synchronizing /Recovery Pending

Имея аналогичный Not Synchronizing /In Recovery , я проверил статус в группе доступности -> Доступность базы данных, но они отображали красный X:

 Группы доступности, базы данных доступности

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

  

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

     

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

     

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

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

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

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

10 голосов | спросил Greg Bray 17 FebruaryEurope/MoscowbWed, 17 Feb 2016 04:01:50 +0300000000amWed, 17 Feb 2016 04:01:50 +030016 2016, 04:01:50

1 ответ


13

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

-- 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;

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

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

ответил Greg Bray 17 FebruaryEurope/MoscowbWed, 17 Feb 2016 04:01:50 +0300000000amWed, 17 Feb 2016 04:01:50 +030016 2016, 04:01:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132