Бази даних розподілених груп доступності SQL Server не синхронізуються після перезавантаження сервера

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

Минулого місяця я модернізував віддалений вторинний сервер із SQL Server 2016 до SQL Server 2017. Цей сервер є частиною декількох груп розподіленої доступності (DAG) та окремої групи доступності (AG) . Коли ми оновили цей сервер, ми не усвідомлювали, що він перейде в нечитабельний стан , тому протягом останнього місяця ми покладалися виключно на основний сервер.

У рамках майбутнього оновлення я застосував патч CU 4 до сервера та перезавантажив його. Коли сервер повернувся до Інтернету, щойно виправлене вторинне повідомлення показало, що всі DAG / AG синхронізуються без проблем.

Однак первинна демонструвала зовсім іншу історію. Це повідомляло

• окремий АГ синхронізувався без жодних питань
• але DAGs були в НЕ Synchronzing / Чи не Здорове стан

Після спочатку паніки я спробував зробити такі речі, щоб знову синхронізуватись у DAG:

• З первинного я зупинився і відновив рух даних. Це не почало синхронізувати дані.
• На вторинному (той, який я щойно латав) я запустив ALTER DATABASE [<database] SET HADR RESUME;- який виконується без помилок, але не відновив синхронізацію

Моєю останньою спробою знову синхронізувати дані було ввійти до вторинного та вручну перезапустити службу SQL Server. Перезапуск служби вручну здається трохи екстремальним, тому що я б очікував, що перезавантаження сервера було б достатньо.

Хтось зіткнувся з цією проблемою, коли DAG не починає синхронізуватись із вторинним після перезавантаження? Якщо так, то як це було вирішено?

Я перевірив і журнал помилок SQL Server, і переглядач подій на вторинному сервері, нічого спільного я не міг бачити.

Зауважте, це не остаточна відповідь, але це найкраща відповідь після спілкування з Тарином .

Однак первинна демонструвала зовсім іншу історію. Він повідомляв, що окремий АГ синхронізується без жодних питань, але групи DAG перебувають у не синхронізованому / не здоровому стані

Якщо окремі бази даних та АГ, що лежать в основі розподіленого агента, заявляють, що вони здорові та синхронізовані, є хороший шанс, що це просто гикавка в інформаційних панелях DMV та / або SSMS. Оскільки в журналі помилок не було нічого, що б припустило, що репліка не з'єднується або перебуває у відключеному стані.

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

• Перевірте sys.dm_hadr_database_replica_states на всіх кластерах, які шукають нічого, що не є здоровим. Якщо все виявляється здоровим, можливо, DMV ще не оновлювався
• Якщо це нездорово, перевірте файл помилок / DMV на проблеми з підключенням (наприклад, неможливість підключення до первинного / глобального первинного)
• У відповіді Дена згадуються проблеми, які можуть виникнути при запуску бази даних - хоча в цьому випадку екземпляр не можна прочитати, так що, швидше за все, це не було проблемою, але може бути у вашому випадку
• Якщо база даних читабельна, випробування на дим за допомогою макетної таблиці / вставки або ...
• Розширений сеанс подій з використанням елементів каналу DEBUG sqlserver.hadr_dump_log_blockабо sqlserver.hadr_apply_log_blockдля того, щоб перевірити, чи вторинний насправді отримує / застосовує блоки журналів або ...
• Об'єкт Perfmon SQLServer:Database Replica\Log Bytes Received/sec

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

Якщо ж це не так, нам потрібно буде далі дослідити, що є поза межами відповіді.

Я передбачу це все із застереженням, що у мене немає жодних DAG у виробництві. Принципово, хоча ця порада має застосовуватись як між АГ, так і з груповими групами.

Чи відновилася синхронізація після перезавантаження служби? Якщо так, то я найкраще здогадаюсь про причину - блокування повторного SPID. Якщо це все ще не синхронізується навіть після перезавантаження, ось що я перевірю спочатку:

Блокування AG повтору SPID

Як правило, це відбуватиметься лише на читальному середньому. Щоб перевірити, запустіть наступне:

select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'

Якщо з’являються якісь блокуючі SPID, вам потрібно буде знищити їх, перш ніж вторинне відновиться ( DB STARTUPSPID - це те, що обробляє повторні операції). Я б запропонував попередньо переглянути блокуючий SPID, щоб спробувати встановити причину (зазвичай це тривалий звіт).

Якщо ви хочете отримати додаткову інформацію з цього питання , є велика стаття (включаючи моніторинг цього типу поведінки з використанням префіксів) тут .

Перевірте DMV

Якщо рух даних призупинено, ви можете звернутися до DMV для отримання додаткової інформації про причину призупинення. Виконайте наступне:

select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states

Стаття BOL трохи далі описує причину suspend_reason.

Чи розподілена ваша група розподіленої доступності (DAG) між різними регіонами? Якщо це так, ви можете страждати від того, що значення за замовчуванням SESSION_TIMEOUT (10 секунд) є занадто низьким. Це означає, що затримка між двома регіонами занадто висока, щоб надійно завершити синхронізацію.

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

Удосконалення: налаштуйте значення SESSION_TIMEOUT для репліки групи розподіленої доступності в SQL Server 2016 та 2017