Альтернатива методу, который заключается в том, чтобы определять, следует ли выполнять логику всякий раз, когда выполняется то или иное задание, состоит в активации или деактивации целых заданий в зависимости от того, выполняются ли они на сервере, который служит хостом для интересующей нас основной реплики. Обзор/требования Чтобы использовать данный подход, потребуется предварительно решить следующие вопросы.
Реализовать логику, обеспечивающую периодическую проверку и переключение в состояние активации/деактивации на серверах. Эта логика строится на идее применения определяемых пользователем функций для решения вопроса о том, является ли соответствующий хост владельцем интересующей нас основной реплики, но затем возникают новые задачи, вытекающие из необходимости активации/деактивации заданий.
С целью более эффективного определения, какие задания следует, а какие не следует активировать, предусмотреть способ ассоциирования заданий с целевой базой данных (или целевой группой доступности). Более подробно о том, как отличить задания уровня сервера от пакетных заданий, было рассказано в статье, опубликованной в предыдущем номере журнала. Этот вопрос важен, поскольку мы не можем исходить из того, что, если основной экземпляр не размещается на том или ином сервере, все задания на данном сервере необходимо деактивировать.
Далее, логика, ответственная за активацию или деактивацию заданий, должна предусматривать возможность аварийного переключения входящей в состав группы доступности базы данных на новый сервер (где, предположим, четыре пакетных задания должны выполняться в упомянутой базе данных). При этом не все задания должны быть автоматически активированы в обязательном порядке просто потому, что упомянутая база данных внезапно превратилась в активную основную. Иными словами, если предполагается, что задание будет выполняться в определенной базе данных, отсюда еще не следует, что оно всегда должно быть активировано.
Как и при использовании всех других подходов, описанных выше, синхронизация деталей заданий на всех серверах, входящих в состав группы доступности AlwaysOn, является строго обязательной.
В дополнение к достоинствам данного подхода, описанным в предыдущей части (то есть к возможностям миновать перечисленные ловушки, хотя многих из них можно избежать и с помощью метода динамического выявления во время исполнения), рассматриваемый подход обеспечивает ряд дополнительных преимуществ.
В противоположность другим подходам, описываемым в данной статье, метод деактивации и активации позволяет с большей легкостью работать с заданиями SS1S, особенно когда этих заданий много. Аналогичные преимущества дает он и при работе с планами по обслуживанию (хотя я не вижу причин иметь их на каждом сервере больше нескольких штук, ибо этим планам можно доверять только операции по резервному копированию, если под рукой у вас нет более надежного решения от стороннего поставщика).
Он проще в управлении при выполнении сложных заданий. В ходе работы со сложными заданиями с большим количеством шагов (я, кстати, обычно не рекомендую связываться с такими заданиями) требуется вставлять логику if/else во все коды и все шаги задания. В ряде случаев, если эти задания часто модифицируются и обновляются, невключение того или иного блока кода в блок if/else может обернуться проблемой. Поэтому проще, пожалуй, пойти по другому пути: активировать (или не активировать) все задание целиком в зависимости от того, размещается ли оно на хосте, содержащем основную реплику.
К сожалению, имеется целый ряд весомых аргументов против использования этого подхода; все они объясняются дополнительной сложностью, которая для него характерна.
Построение заданий, которые активируют/деактивируют задания и создание механизмов, отслеживающих активированное/деактивированное состояние различных заданий, — это, конечно, не бином
Ньютона, но это сложнее, чем просто разместить логику if/else вокруг кода, который вы хотите выполнить внутри простых заданий.
Комментарии