База даних SQL Server AlwaysOn затрималася в режимі не синхронізації / в режимі відновлення після оновлення. Помилка. Неможливо відкрити базу даних "..." версії 782

Під час тестування оновлення з SQL Server 2014 SP1 (12.0.4422.0) до SQL Server 2016 CTP 3.2 (13.0.900.73) я дотримувався рекомендованого процесу оновлення і зіткнувся з проблемою, коли база даних не запускатиметься на старій основній системі після відмови до оновленого середнього. Наша настройка - це первинна та одна вторинна репліки, і кроки, які я виконала, були:

1. Видаліть автоматичну відмову у вторинній копії синхронно-фіксує
2. Оновлення екземплярів вторинного сервера до нової версії
3. Вручну перейти до вторинної репліки
4. Перевірте онлайн-бази даних за допомогою нової основної репліки
5. Оновіть попередню первинну репліку до нової версії

Оновлення вторинного та відмовного режиму, щоб зробити його первинним, працювало точно так, як очікувалося. Але після оновлення попередньої первинної репліки я помітив, що бази даних на ній були занесені до SSMS як « Не синхронізуючий / відновлений» . Також спроба отримати доступ до них створить повідомлення про помилку:

База даних ... недоступна. (ObjectExplorer)

Перевірка через журнали SQL Server

Неможливо відкрити базу даних '...' версії 782. Оновіть базу даних до останньої версії.

Запит на таблицю master..sysdatabases показав, що це дійсно старіша версія і не оновлювалася під час оновлення:

На жаль, журнали не вказували, чому він не оновлювався, і на інформаційній панелі груп доступності було лише загальне попередження, яке вказує, що стан синхронізації даних деякої бази даних не є здоровим, без жодної причини.

Я спробував за допомогою TSQL від'єднати бази даних або встановити їх в автономному режимі, щоб "запустити" його в оновлення, але оскільки вони є частиною SQL AG, ці команди не працюють.

Як я можу оновити базу даних до останньої версії, коли вона є частиною SQL AG?

Якось деякий час обзивавшись у SSMS, я помітив, що на вторинній репліку поруч із базами даних про доступність знаходився значок паузи. Основний показав, що обидва були "зеленими", але існувала опція на вторинному для відновлення руху даних . Я відновив першу базу даних, і відразу повідомлення про стан відновлення було видалено. Через хвилину він змінився з Не синхронізований на Синхронізований, і все працювало так, як очікувалося.

Ось скріншот баз даних AG після того, як я встановив "Patch", але перед виправленням тестової бази даних:

Зауважте, що ви також можете використовувати TSQL на вторинному пристрої для відновлення реплікації в декількох базах даних одночасно:

ALTER DATABASE [Patch] SET HADR RESUME;
ALTER DATABASE [test] SET HADR RESUME;
GO