Группы доступности AlwaysOn и задания SQL Server: нестандартный метод работы с аварийными переключениями и активацией заданий
Содержание:
1. Управление заданиями с помощью главных серверов;
2. «Продвинутые» системы ;
3. Дополнительные способы аварийных переключений заданий;
4.Еще один способ работы с аварийными переключениями и активацией заданий (Вы читаете данный раздел).
Несколько месяцев назад Том Мейер прислал мне электронное письмо, в котором изложил — в качестве примера более простого, организованного подхода к управлению заданиями — другой взгляд на проблему управления заданиями на серверах, где размещаются группы доступности. Он следил за публикацией данной серии статей, и ему захотелось поделиться со мной другим видением управления заданиями. А у меня, в свою очередь, возникло желание поделиться этими соображениями со всеми читателями.
Логика Тома и его подход к решению проблемы организованы намного более четко, чем мои. И ему удается с их помощью добиваться успеха главным образом потому, что Мейер убежден: регулярные «проверки синхронизации» не нужны, и ему не приходится следить за тем. какие задания активированы, а какие деактивированы. По этой причине Том выработал в конечном итоге гораздо более простой подход к управлению заданиями. Вот как он определяет данный процесс.
• Создайте категорию или категории заданий для всех заданий, которые хотите синхронизировать.
• Поместите в них все задания. Если вы вручную обновите категорию на ряде заданий посредством обновления таблицы системных заданий, вам придется осуществить повторный запуск агента, иначе в случае попытки повторно открыть это задание агент выдаст сообщение об ошибке.
• Хранимая процедура проходит через все эти задания с использованием следующей логики:
- если есть основная реплика и она деактивирована, активируйте ее;
- если есть основная реплика и она активирована, не предпринимайте никаких действий;
- если есть дополнительная реплика и она активирована, деактивируйте ее;
- если есть дополнительная реплика и она деактивирована, не предпринимайте никаких действий.
• Создайте задание агента, запускающее хранимую процедуру для определенных категорий. Создайте оповещение для сообщения 1480.
• Определите ответ на это оповещение с целью выполнения задания.
Управление заданиями
Взяв этот подход на вооружение, Гом устраняет необходимость проведения по истечении определенного количества минут «проверок синхронизации» и вполне может обходиться без таблицы состояний. Кроме того, ему не требуются связанные серверы (для осуществления проверок синхронизации), что позволяет дополнительно упростить задачу. В коде выше приведен пример кода, используемого Томом. В целом, это простое и изящное решение, абсолютно обоснованное в случаях, когда вам не приходится беспокоиться по поводу проблем, описанных мною в начале статьи (то есть связанных с управлением изменениями, а также с активацией и деактивацией заданий). Подобным же образом, если перед вами не стоит проблема управления изменениями. но вы хотите сохранить возможность активации или деактивации заданий, вы сможете с легкостью адаптировать подход Гома к своей ситуации и включить в код таблицу состояний или, возможно, создать новую категорию заданий под названием, скажем, AGSuchAndSuch-Disabled, с помощью которой будете решать сходные задачи без составления таблицы состояний.
Словом, способов решения проблемы управления заданиями имеется множество. Ответ на вопрос о том, какой из них больше всего подойдет для вас, зависит от вашей рабочей среды, принятых в организации установок и от ваших потребностей.
1. Управление заданиями с помощью главных серверов;
2. «Продвинутые» системы ;
3. Дополнительные способы аварийных переключений заданий;
4.
Несколько месяцев назад Том Мейер прислал мне электронное письмо, в котором изложил — в качестве примера более простого, организованного подхода к управлению заданиями — другой взгляд на проблему управления заданиями на серверах, где размещаются группы доступности. Он следил за публикацией данной серии статей, и ему захотелось поделиться со мной другим видением управления заданиями. А у меня, в свою очередь, возникло желание поделиться этими соображениями со всеми читателями.
Логика Тома и его подход к решению проблемы организованы намного более четко, чем мои. И ему удается с их помощью добиваться успеха главным образом потому, что Мейер убежден: регулярные «проверки синхронизации» не нужны, и ему не приходится следить за тем. какие задания активированы, а какие деактивированы. По этой причине Том выработал в конечном итоге гораздо более простой подход к управлению заданиями. Вот как он определяет данный процесс.
• Создайте категорию или категории заданий для всех заданий, которые хотите синхронизировать.
• Поместите в них все задания. Если вы вручную обновите категорию на ряде заданий посредством обновления таблицы системных заданий, вам придется осуществить повторный запуск агента, иначе в случае попытки повторно открыть это задание агент выдаст сообщение об ошибке.
• Хранимая процедура проходит через все эти задания с использованием следующей логики:
- если есть основная реплика и она деактивирована, активируйте ее;
- если есть основная реплика и она активирована, не предпринимайте никаких действий;
- если есть дополнительная реплика и она активирована, деактивируйте ее;
- если есть дополнительная реплика и она деактивирована, не предпринимайте никаких действий.
• Создайте задание агента, запускающее хранимую процедуру для определенных категорий. Создайте оповещение для сообщения 1480.
• Определите ответ на это оповещение с целью выполнения задания.
Управление заданиями
Взяв этот подход на вооружение, Гом устраняет необходимость проведения по истечении определенного количества минут «проверок синхронизации» и вполне может обходиться без таблицы состояний. Кроме того, ему не требуются связанные серверы (для осуществления проверок синхронизации), что позволяет дополнительно упростить задачу. В коде выше приведен пример кода, используемого Томом. В целом, это простое и изящное решение, абсолютно обоснованное в случаях, когда вам не приходится беспокоиться по поводу проблем, описанных мною в начале статьи (то есть связанных с управлением изменениями, а также с активацией и деактивацией заданий). Подобным же образом, если перед вами не стоит проблема управления изменениями. но вы хотите сохранить возможность активации или деактивации заданий, вы сможете с легкостью адаптировать подход Гома к своей ситуации и включить в код таблицу состояний или, возможно, создать новую категорию заданий под названием, скажем, AGSuchAndSuch-Disabled, с помощью которой будете решать сходные задачи без составления таблицы состояний.
Словом, способов решения проблемы управления заданиями имеется множество. Ответ на вопрос о том, какой из них больше всего подойдет для вас, зависит от вашей рабочей среды, принятых в организации установок и от ваших потребностей.
