Группы доступности AlwaysOn и задания SQL Server: заключительные соображения относительно резервных копий
Содержание:
1. Синхронизация пакетов SSIS, размещенных на разных серверах;
2. Сохранение согласованности пакетов;
3.
Рекомендации по работе с резервными копиями групп доступности AlwaysOn
Как вы, возможно, догадались, рекомендации по управлению резервными копиями в средах с использованием групп доступности принципиально не отличаются от рекомендаций для работы с обычными базами данных. Единственное отличие состоит в том, что в первом случае администратору приходится иметь дело с рядом дополнительных опасностей и ловушек.
Перечислим, что нужно сделать и за чем проследить в процессе управления резервными копиям и для групп доступности AlwaysOn.
• Обеспечьте регулярное тестирование резервных копий. В одних сетях достаточно будет делать это раз в неделю или раз в месяц, в других даже интервал в сутки может оказаться слишком большим — только вы можете судить о том, насколько важно для ваших данных находиться под постоянной зашитой; и не забывайте, что данные высокой доступности не относятся к той же категории, что и данные, защищаемые от аварийных отказов, таких как определенные формы повреждений, программные сбои, ошибки пользователей и т. д.
• Обязательно документируйте все процессы и процедуры, необходимые для восстановления данных в чрезвычайной ситуации. Подготовкой такой документации дол жен заниматься сотрудник, который может дать разъяснения по максимальному числу чрезвычайных ситуаций и задокументировать способы выхода из таких ситуаций или пояснения к ним, но написана она должна быть на уровне, понятном для техников младшего звена, поскольку, скорее всего, именно такие специалисты прибудут по вызову или будут находиться на дежурстве в момент сбоя базы данных.
• Позаботьтесь о том, чтобы у вас под рукой были соглашения об уровне обслуживания или документы, определяющие допустимый объем возможных потерь данных, а также приемлемое время простоя в случае сбоя; они помогут вам определить показатели эксплуатационной готовности. Если эти показатели не будут четко определены и доступны, вы просто не сможете добиться успеха. Возможно, вы восстановите данные после катастрофического сбоя, однако может статься, что никто из руководства не имеет ни малейшего понятия о том, что система SQL Server может простаивать в течение какого-то времени, и никто не будет ожидать «настоящего» простоя, потому что, согласно представлениям руководства, вы заплатили за оборудование и лицензии SQL Server, а значит, получили гарантию того, что ваши базы данных всегда доступны.
• Обязательно проследите за тем, чтобы ваша документация содержала сведения о том, как осуществляется диагностика максимально широкого круга неисправностей (отказы кластеров, повреждения баз данных, поврежденные или взломанные базы данных, потенциально поврежденные базы данных и т. п.).
• Проследите за тем, чтобы в ваших документах по восстановлению после аварийного сбоя содержалась информация о том, какой более высокой инстанции следует передавать вопросы (включая актуальную контактную информацию), если события будут разворачиваться не так, как вы ожидали.
• Обязательно проследите за тем, чтобы точные сведения о месте размещения резервных файлов и о том, как вы построили архитектуру резервных копий групп доступности AlwaysOn, были задокументированы (то есть речь идет о том, как была определена предпочтительная реплика, куда пересылаются файлы и т. д.).
• Обеспечьте регулярное обновление документации.
Выполняя перечисленные базовые рекомендации по управлению резервными копиями, вы должны в то же время держать в поле зрения некоторые обстоятельства (или «подводные камни»),
• Если вы исправно проверяете работу групп доступности перед их развертыванием в рабочих сетях, то знаете, что процедура восстановления данных с резервных копий — дело нелегкое, поскольку восстановление не может осуществляться «через голову» базы данных, входяoей в состав группы доступности (в том смысле, что эту базу нужно будет извлекать из группы доступности или вообще полностью расформировывать последнюю до начала восстановления, а после восстановления вам, разумеется, придется повторно инициализировать синхронизацию базы данных, вновь включая ее в состав группы доступности).
• С учетом упомянутых сложностей (а также высокой вероятности простоев) у вас возникает реальная потребность в приобретении агента чтения журнала от стороннего поставщика. Подобный агент поможет вам справиться с ситуациями, связанными с «логическим повреждением» данных, или пригодится в случаях, когда целостность вашей базы данных нарушена. Так вот, агент чтения журнала от стороннего поставщика позволит вам восстановить данные после сбоя (если вы располагаете добротными резервными копиями), не требуя при этом начинать все с чистого листа и не вынуждая вас переводить системы в автономный режим или восстанавливать все данные на момент времени, предшествующий их повреждению.
Кроме того, вам нужно будет обращать особое внимание на «фрагментацию» резервных копий (рассмотренную в одной из статей серии), а также обеспечивать корректную «синхронизацию» заданий резервного копирования и логических схем на всех хостах для реплик (как описано в предыдущих статьях). Итак, с резервными копиями мы разобрались, и теперь пора переходить к четвертому разделу настоящей серии, в котором я рассмотрю более сложные темы (такие, как главные серверы, группы доступности, размещаемые в нескольких подсетях, и т. д.) и расскажу о некоторых альтернативных вариантах решения проблем управления заданиями и синхронизации.
