На первый взгляд идея активации и деактивации заданий агента SQL Server не должна вызывать особых затруднений, но здесь есть некоторые тонкости. Прежде всего, мы должны помнить, что данный подход или данный прием неприменим к заданиям уровня экземпляра или сервера, поскольку такие зада ния должны быть активированы на всех серверах, где размещается та или иная группа доступности AlwaysOn. Сказанное касается и резервных копий — они представляют собой нечто совершенно иное.
Опять-таки читателей, желающих получить более подробную информацию, я отсылаю к статье об определении пакетных заданий. В остальных случаях вся идея активации и деактивации заданий сводится к следующему. Если нам нужно реализовать пакетное задание, которое выполняется в целевой базе данных MyDatabase и эта база данных размещается в простой, состоящей из двух узлов группе доступности таким образом, что база данных MyDatabase размещается на двух различных серверах/экземплярах, нам необходимо, чтобы логика данного пакетного задания выполнялась в основной реплике.
Таким образом, задание агента SQL Server на основном сервере должно быть активировано, тогда как дополняющий его дубликат или клон на вспомогательном сервере должен быть деактивирован (для того, чтобы этот дубликат не выполнялся, не пытался внести изменения в собственную восстанавливаемую копию базы данных и не выдавал сообщения об ошибках).
На первый взгляд идея активации и деактивации заданий агента SQL Server не должна вызывать особых затруднений, но здесь есть некоторые тонкости
Однако реализация изложенной выше логики может вступить в конфликт с рядом практических обстоятельств.
Очевидно, что нам требуется средство для отслеживания того, какие задания нужно активировать/деактивировать в зависимости от их связи с целевой базой данных, входящей в состав группы доступности. Или, иными словами, если у нас на сервере развернуто 18 заданий агента SQL Server, но только три из них представляют собой пакетные задания, которые должны выполняться в одной из баз данных, входящих в состав нашей группы доступности (AG), мы не имеем права, не углубляясь в детали, исходить из того, что можем активировать или деактивировать все 18 размещенных на сервере заданий в зависимости от того, размещается ли на этом сервере интересующая нас основная реплика. Вместо этого нам следует ограничиться изменением статуса трех наших AG-заданий с «активировано» на «деактивировано» и обратно.
Далее, то обстоятельство, что мы смогли отличить три задания уровня AG от остальных 15 размещенных на сервере заданий, не дает нам оснований без дальнейших разбирательств указывать, какие из этих заданий должны быть активированы на сервере после аварийного переключения. Предположим, что одно из трех заданий уровня AG было намеренно деактивировано администраторами, скажем, на несколько дней. Допустим также, что на сервере Serverl в данный момент размещается основная реплика нашей целевой базы переходим на другой сервер, все три задания уровня AG на сервере Serverl должны быть деактивированы.
Но мы не можем огульно заключить, что все три задания уровня AG должны быть активированы на сервере Server2. Если мы допустили такое предположение, у нас возникнут проблемы. Правда, мы можем опросить Serverl, дабы выяснить, каков был статус тех трех заданий, но ведь весь смысл применения групп доступности и аварийных переключений как раз в том и состоит, что в ситуации, когда произойдет аварийное переключение, Serverl, скорее всего, будет недоступен для опроса.
Поэтому нам нужны другие средства отслеживания состояния заданий уровня группы доступности (то есть определения, были ли они явным образом отключены администраторами так, что их можно оставить в состоянии деактивации после аварийного переключения).
Комментарии