Групи доступності alwayson і завдання sql server: нестандартний метод роботи з аварійними перемиканнями і активацією завдань

Відео: Always On Availability Groups enhancements in SQL Server 2016

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

Логіка Тома і його підхід до вирішення проблеми організовані набагато чіткіше, ніж мої. І йому вдається з їх допомогою досягати успіху головним чином тому, що Мейер переконаний: регулярні «перевірки синхронізації» не потрібні, і йому не доводиться стежити за тим. які завдання активовані, а які деактивовані. З цієї причини Том виробив в кінцевому підсумку набагато більш простий підхід до управління завданнями. Ось як він визначає даний процес.

• Створіть категорію або категорії завдань для всіх завдань, які потрібно синхронізувати.

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

• Процедура проходить через всі ці завдання з використанням наступної логіки:



- якщо є основна репліка і вона деактивовано, активуйте її;
- якщо є основна репліка і вона активована, не робіть ніяких дій;
- якщо є додаткова репліка і вона активована, деактивуйте її;



- якщо є додаткова репліка і вона деактивовано, не робіть ніяких дій.

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

• Визначте відповідь на це сповіщення з метою виконання завдання.

Взявши цей підхід на озброєння, Гом усуває необхідність проведення після закінчення певної кількості хвилин «перевірок синхронізації» і цілком може обходитися без таблиці станів. Крім того, йому не потрібні пов`язані сервери (для здійснення перевірок синхронізації), що дозволяє додатково спростити завдання. У коді вище наведений приклад коду, використовуваного Томом. В цілому, це просте і витончене рішення, абсолютно обґрунтоване у випадках, коли вам не доводиться турбуватися з приводу проблем, описаних мною на початку статті (тобто пов`язаних з управлінням змінами, а також з активацією і деактивацією завдань). Подібним же чином, якщо перед вами не стоїть проблема управління змінами. але ви хочете зберегти можливість активації або деактивації завдань, ви зможете з легкістю адаптувати підхід Гома до своєї ситуації і включити в код таблицю станів або, можливо, створити нову категорію завдань під назвою, скажімо, AGSuchAndSuch-Disabled, за допомогою якої будете вирішувати подібні завдання без складання таблиці станів.


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