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

Під час оновлення сховища в екземплярі SQL Server 2014 SP1 (12.0.4422.0) ми зіткнулися з проблемою, коли дві бази даних не запускатимуться на вторинній основі після перезавантаження SQL Server. Сервер був в автономному режимі протягом декількох годин, поки ми встановили нові (більші) SSD та скопіювали файли даних на новий об'єм. Коли ми перезапустили SQL Server, всі, крім двох баз даних, знову почали синхронізуватися. Інші два відображалися в SSMS як не синхронізовані / відновлені .

Маючи подібну проблему з не синхронізацією / відновленням у відновленні , я перевірив стан у розділі Групи доступності -> Бази даних про доступність, але вони відображали червоний X:

і навіть намагаючись призупинити рух даних, генерується повідомлення про помилку:

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

Додаткова інформація: Виняток стався під час виконання оператора або пакетної операції SQL. (Microsoft.SqlServer.ConnectionInfo)

Базу даних "StackExchange.Bycycles.Meta" неможливо відкрити через недоступні файли або недостатню кількість пам'яті або місця на диску. Докладніше див. Журнал помилок SQL Server. (Сервер Microsoft Sql, помилка: 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. В цей час це може вказувати, що БД вторинного вузла не синхронізується, а просто виконує те, що пропонується у другій відповіді (Купіть так, як було покарано -2), я маю на увазі переміщення Вторинного вузла до первинного, він це виправить.

Наступного разу спробуйте перейти на первинний до "не синхронізувати" вторинне та знову. Вторинний зараз має бути синхронізованим.