Одно из важнейших достоинств групп доступности AlwaysOn состоит в том, что эти группы обеспечивают, что называется, в одном пакете как высокую доступность (или отказоустойчивость), так и способность к восстановлению после аварийного сбоя (или способность поддерживать согласованность размещенных вне компании данных на случай непредвиденных ситуаций). Иначе говоря, администраторы баз данных и системные администраторы, освоившие все тонкости этой технологии (что не так просто, как может показаться), смогут решать вопросы, касающиеся высокой доступности и восстановления после аварийного сбоя, с помощью одного интерфейса управления или набора инструментов, что обеспечит большую масштабируемость управления.

Но здесь нужно сделать одно важное замечание: группы доступности AlwaysOn не обеспечивают защиты от сбоев, вызванных действиями пользователей или незаконными приложениями. Сформулируем это иначе: реализованные в группах доступности компоненты, обеспечивающие высокую доступность и восстановление после аварийного сбоя, выполняют свои функции посредством зеркального отображения данных на нескольких серверах (за счет чего защита внутри центров обработки данных осуществляется средствами высокой доступности и отказоустойчивости, а вне центров обработки данных — средствами зеркалирования данных за пределами территории компании).

Но эта конструкция строится на предпосылке, что зеркалированные данные всегда корректны. Если вследствие программного сбоя, действий конечного пользователя, администратора баз данных или разработчика либо под воздействием любого другого фактора данные подвергнутся непреднамеренному разрушению или взлому, эти данные будут по-прежнему характеризоваться высокой доступностью и отказоустойчивостью — но они будут неверны. В большинстве организаций такую ситуацию следует признать катастрофической. Разве кого-то может заинтересовать вопрос о том, насколько быстро передаются ваши данные и насколько они актуальны, если это неверные данные?

В подобных ситуациях группы доступности AlwaysOn вам не помогут (как, впрочем, и другие средства обеспечения высокой доступности). Здесь не обойтись без резервной копии.

Проблема использования резервных копий при наличии групп доступности AlwaysOn

Надо сказать, что в случае использования резервных копий в среде, где существуют группы доступности AlwaysOn, возникает одна проблема, которая состоит в том, что восстановление резервной копии поверх базы данных, которая является частью группы доступности, невозможно. Так что администратор вынужден либо расформировывать группу доступности, либо выводить из состава группы соответствующую базу данных (имеются аргументы в пользу того, что предпочтительным, возможно, является либо первое, либо второе из представленных решений), а затем, когда зеркальное дублирование базы данных прекращается, восстановление может быть осуществлено поверх нее. Но дело в том, что этот подход имеет два серьезных недостатка.

Начнем с первого (наиболее очевидного). Идет ли речь о расформировании группы доступности или об удалении из нее базы данных с последующим восстановлением группы и перестройкой ее составных частей в соответствии с тем, какой вид она имела до аварийного сбоя, работа неизбежно окажется трудоемкой, требующей значительного времени, и при ее выполнении высока вероятность ошибок. Кроме того, вы не получите выигрыша в плане общего соотношения «период работоспособности/доступность».

Второй недостаток очевиден для каждого, кому хоть раз поручали привести данные в состояние до того, как «этот неумеха из группы разработчиков угробил все наши сведения о клиентах, выполнив предложение UPDATE без использования оператора WHERE». Этот недостаток состоит в том, что хотя вы и сможете привести данные в состояние, в котором они пребывали ДО того, как были уничтожены вследствие ошибки пользователя, позднее вы столкнетесь с рядом проблем. Вы окажетесь перед выбором: или возвращать всю базу данных целиком в состояние до момента разрушения данных — и при этом терять все последующие изменения/модификации во всех таблицах, — или вам придется проверить правильность копии базы данных, которую вы пытаетесь восстановить, привести ее в состояние до момента разрушения данных и затем вручную создать предложения UPDATE. .. FROM, которые перенесут данные из восстановленной копии вашей базы данных и запишут их поверх «разрушенных» данных.

Это в высшей степени утомительное занятие, в ходе которого вы можете совершить множество ошибок и в конце концов не сможете восстановить изменения, внесенные после того, как данные были разрушены. Представьте себе таблицу, использовавшуюся для отслеживания материально-производственных запасов, в которой объемы всех наличных продуктов каким-то образом получили значение InventoryCount = 0. И если вы вернетесь к уровням/значениям, отмечавшимся до того, как имела место непреднамеренная перезапись, это будет возвращением к положению вещей до катастрофического сбоя; но осуществлялось ли увеличение/уменьшение запасов за то время, пока вы устраняли последствия катастрофы? Если да, то зафиксированные вами уровни товарно-материальных запасов по-прежнему неточны.

Одно из ключевых преимуществ второго подхода состоит в том, что проверка правильности копии базы данных с помощью зеркально отображенной и входящей в состав группы доступности базы избавляет администратора от необходимости переносить эти данные из группы доступности или прекращать их зеркальное отображение. Отмечу также, что, описывая оба приведенные выше сценария, я исхожу из того, что в вашем распоряжении имеются резервные копии FULL/FULL+DIFF и Transaction Log.

Использование агента чтения журналов стороннего производителя

Более простой способ восстановления данных после сбоев, вызванных ошибками пользователей, состоит, конечно, в том, чтобы в первую очередь не допускать подобных сбоев (то есть не предоставлять пользователям такой доступ к производственным системам, который оставляет им возможность выполнять предложения UPDATE, DELETE и т.д.). Впрочем, в ряде сетей, с которыми мне довелось работать, сделать это не так-то просто. К тому же во всех сетях существует опасность того, что в определенных ситуациях причиной повреждения тех или иных данных может стать программный сбой или ошибка. Отсюда, в свою очередь, следует, что для решения подобных задач администратор должен всегда иметь под рукой некий план действий на случай непредвиденных обстоятельств.

И в этих ситуациях моих настоятельных рекомендаций будет недостаточно для того, чтобы воздать должное агентам чтения журналов. Если отвлечься от подробностей, эти агенты используют то обстоятельство, что в журнале транзакций баз данных SQL Server фиксируются значения BEFORE и AFTER, характеризующие то, как данные должны выглядеть до и после каждого отдельно взятого изменения, внесенного в базу данных. Агенты чтения журналов, исследуя журнал транзакций, могут помочь администраторам баз данных и сисадминам отыскать конкретные операции или изменения и затем сгенерировать сценарии, которые в сущности будут возвращать или отменять те или иные изменения. Для этого они будут создавать предложения UPDATE, которые будут переводить данные в состояние, предшествующее рассматриваемому происшествию.

Мало того, с помощью тех же самых инструментов вы можете исследовать журналы в поисках любых изменений, внесенных в интересующие вас данные/записи, и перейти как вперед, так и назад, к моменту любых последующих (не-ошибочных/не-случайных) изменений. Так, в случае, когда объемы всех имеющихся материально-производственных запасов непреднамеренно сведены к нулю, агент чтения журналов может как заменить эти значения теми, что использовались до сбоя, так и обеспечить повторное выполнение (или фиксацию) индивидуальных предложений UPDATE, которые, возможно, ранее повышали либо понижали уровень складских запасов тех или иных продуктов.

Учитывая, что группы доступности AlwaysOn входят в комплект поставки версии Enterprise Edition, ясно, что расходы на приобретение агента чтения журналов от стороннего производителя (составляющие от 700 до 1600 долл.) — всего лишь капля в море общих затрат.

К тому же с учетом того, что один из этих инструментов может стать для вас настоящей «палочкой-выручалочкой» в случае бедствия — обеспечивая при этом возможность работы баз данных/групп доступности в то время, как администратор «переливает» журналы, а также находит/создает решение проблемы — само собой разумеется, что агент Third Party Log Reader должен входить в набор инструментальных средств каждого администратора баз данных, осуществляющего управление группами доступности AlwaysOn (отказ от приобретения такого решения обойдется вам слишком дорого).

Агенты чтения журналов

ApexSQL Log (www.apexsql.com/sql_tools_log.aspx) — мой безусловный фаворит. Разработчики этого продукта сориентировали его исключительно на роль агента чтения журналов — и он справляется с этой задачей просто безупречно.

Toad for SQL Server (www.quest.com/toad-for-sql-server) фактически поставляется с агентом чтения журналов, который является вполне достойным дополнительным компонентом продукта, уже полюбившегося многим администраторам баз данных.