Общие сведения об обеспечении непрерывности бизнес-процессов с помощью Базы данных SQL Azure и Управляемого экземпляра SQL Azure

Область применения:База данных SQL Azure Управляемый экземпляр SQL Azure

Непрерывность бизнес-процессов в Базе данных SQL Azure и Управляемом экземпляре SQL относится к механизмам, политикам и процедурам, которые позволяют вашим бизнес-процессам продолжать работу при возникновении сбоев, особенно в вычислительной инфраструктуре. В большинстве случаев База данных SQL Azure и Управляемый экземпляр SQL будут обрабатывать аварийные события, которые могут произойти в облачной среде, и поддерживать выполнение приложений и бизнес-процессов. Однако существуют аварийные события, которые База данных SQL Azure не может обработать автоматически, например:

  • Пользователь случайно удалил или обновил строку в таблице.
  • Злоумышленник удалил данные или базу данных.
  • Землетрясение вызвало сбой электроэнергии и временно отключил центр обработки данных или любое другое катастрофическое событие стихийных бедствий.

В этом обзоре описываются возможности Базы данных SQL и Управляемого экземпляра SQL по обеспечению непрерывности бизнес-процессов и аварийного восстановления. Вы узнаете о параметрах, рекомендациях и руководствах по восстановлению после аварийных событий, которые могут приводить к потере данных или недоступности базы данных и приложений. Здесь также содержатся сведения о том, как действовать в ситуациях, когда ошибка пользователя или приложения нарушает целостность данных, происходит сбой региона Azure или приложение требует обслуживания.

Функции базы данных SQL, которые можно использовать для обеспечения непрерывности бизнес-процессов

С точки зрения базы данных существуют четыре основных сценария возможных нарушений:

  • Локальные сбои оборудования или программного обеспечения, затрагивающие узел базы данных, например сбой диска.
  • Повреждение или удаление данных, которое, как правило, возникает из-за ошибки приложения или пользователя. Такие сбои зависят от приложения и обычно не могут быть обнаружены службой базы данных.
  • Отключение центра обработки данных, возможно, вызванное стихийным бедствием. Этот сценарий требует определенного уровня геоизбыточности с отработкой отказа приложений в альтернативном центре обработки данных.
  • Ошибки обновления или обслуживания, непредвиденные проблемы, возникающие во время планового обновления или обслуживания или обновления инфраструктуры. Они могут потребовать быстрого отката к предыдущему состоянию базы данных.

Чтобы устранить неполадки с локальным оборудованием и программным обеспечением, в Базе данных SQL предусмотрена архитектура высокой доступности, которая гарантирует автоматическое восстановление после таких сбоев при использовании Соглашения об уровне обслуживания на уровне до 99,995 %.

Для защиты вашей компании от потери данных База данных SQL и Управляемый экземпляр SQL автоматически создают полные резервные копии (раз в неделю) и разностные резервные копии базы данных (каждые 12 часов), а также резервные копии журнала транзакций (раз в 5–10 минут). Резервные копии для всех уровней служб хранятся в хранилище RA-GRS в течения по крайней мере семи дней. Все уровни обслуживания, за исключением Basic, поддерживают настраиваемый период хранения резервных копий для восстановления до точки во времени продолжительностью до 35 дней.

База данных SQL и Управляемый экземпляр SQL также предоставляют несколько функций обеспечения непрерывности бизнес-процессов, которые можно использовать для устранения последствий в различных незапланированных сценариях.

Восстановление базы данных в том же регионе Azure

Для восстановления базы данных до точки во времени в прошлом можно использовать автоматическое резервное копирование базы данных. Таким образом можно выполнить восстановление после повреждения данных, вызванного ошибками человека. Восстановление на момент времени позволяет создать новую базу данных на том же сервере, который представляет состояние данных до события повреждения. Для большинства баз данных операции восстановления выполняются менее 12 часов. Очень большая или активная база данных может восстанавливаться дольше. Дополнительные сведения см. в разделе Время восстановления.

Если для вашего приложения недостаточно максимального поддерживаемого периода хранения резервных копий для восстановления до точки во времени (PITR), его можно увеличить, настроив для баз данных долгосрочную политику хранения (LTR). Дополнительные сведения см. в разделе Долгосрочное хранение резервных копий.

Сравнение георепликации с группами отработки отказа

Группы автоматической отработки отказа упрощают развертывание и использование георепликации и предоставляют дополнительные возможности, как описано в следующей таблице.

Георепликация Группы отработки отказа
Автоматическая отработка отказа Нет Да
Одновременная отработка отказа нескольких баз данных Нет Да
Пользователь должен обновить строку подключения после отработки отказа Да Нет
Поддержка Управляемого экземпляра SQL Нет Да
Может находиться в том же регионе, что и первичная реплика Да Нет
Несколько реплик Да Нет
Поддерживает масштабирование для чтения Да Да

Восстановление базы данных на имеющемся сервере

В редких случаях возможен сбой центра обработки данных Azure. Такой сбой вызывает нарушение работы компании, которое может длиться от считанных минут до нескольких часов.

  • Один из вариантов — дождаться возобновления работы базы данных после того, как сбой центра обработки данных будет устранен. Это подходит для приложений, которые допускают отключение базы данных от сети. Например, вам не нужно непрерывно работать с проектом по разработке или бесплатной пробной версией. После того как произошел сбой центра обработки данных, неизвестно, как долго будет длиться простой. Поэтому этот вариант используется, только если база данных некоторое время не нужна.
  • Другим вариантом является восстановление базы данных на любом сервере в любом регионе Azure с использованием резервных копий геоизбыточных баз данных (геовосстановление). В качестве источника геовосстановление использует геоизбыточную резервную копию для восстановления базы данных, даже если она или центр обработки данных недоступны из-за сбоя.
  • Наконец, после сбоя можно быстро восстановить данные, если настроено использование активной георепликации для вторичной геореплики или применений групп автоматической отработки отказа для одной или нескольких баз данных. В зависимости от выбора технологии можно использовать переход на другой ресурс автоматически или вручную. Хотя отработка отказа занимает всего несколько секунд, службе понадобится как минимум 1 час, чтобы активировать ее. Нужно удостовериться, что отработка отказа соответствует масштабу сбоя. Кроме того, при отработке отказа возможна небольшая потеря данных из-за характера асинхронной репликации.

При разработке плана обеспечения непрерывности бизнес-процессов нужно понимать, какое максимальное время до полного восстановления приложения после аварийного события допустимо. Время, необходимое приложению для полного восстановления, называется целевым временем восстановления (RTO). Необходимо также понимать, потерю какого максимального периода последних обновлений данных (т. е. за какой интервал времени) может допустить приложение при восстановлении после незапланированного аварийного события. Возможная потеря данных называется целевой точкой восстановления (RPO).

Различные методы восстановления предлагают разные уровни RPO и RTO. Можно выбрать конкретный метод восстановления или использовать сочетание методов для полного восстановления приложения. В следующей таблице сравниваются RPO и RTO для каждого варианта восстановления. Группы автоматической отработки отказа упрощают развертывание и использование георепликации и предоставляют дополнительные возможности, как описано в следующей таблице.

Метод восстановления RTO RPO
Геовосстановление из геореплицированных резервных копий 12 h 1 ч
Группы автоматической отработки отказа 1 ч 5 с
Отработка отказа базы данных вручную 30 с 5 с

Примечание

Отработка отказа базы данных вручную означает отработку отказа отдельной базы данных до геореплицированной вторичной реплики с использованием незапланированного режима. Для дополнительной информации об автоматической отработке отказа RTO и RPO см. таблицу, приведенную выше.

Используйте группы автоматической отработки отказа, если приложение соответствует любому из следующих критериев:

  • оно является критически важным;
  • его условия Соглашения об уровне обслуживания (SLA) не допускают более 12 часов простоя;
  • его простой может повлечь финансовую ответственность;
  • имеет высокую частоту изменения данных, и потеря данных за час не допускается;
  • дополнительные затраты на активную георепликацию ниже, чем потенциальная финансовая ответственность и связанная с ней утрата деловых возможностей.

Вы можете использовать сочетание резервных копий базы данных и активной георепликации, в зависимости от требований приложения. Вопросы разработки для автономных баз данных и эластичных пулов, использующих эти возможности обеспечения непрерывности бизнес-процессов, рассматриваются в статьях Разработка глобально доступных служб с помощью Базы данных SQL Azure и Стратегии аварийного восстановления для приложений с использованием пула эластичных баз данных SQL.

В следующих разделах описываются инструкции по восстановлению с использованием резервных копий базы данных или активной георепликации. Подробные инструкции, включающие в себя планирование требований, действия после восстановления и сведения о том, как имитировать сбой для отработки аварийного восстановления, см. в статье Восстановление базы данных в Базе данных SQL Azure или переход на базу данных-получатель при отказе.

Подготовка к сбою

Независимо от выбранной функции обеспечения непрерывности бизнес-процессов необходимо выполнить следующее.

  • Определите и подготовьте целевой сервер, включая правила брандмауэра для IP-адресов, имена для входа и разрешения уровня базы данных master.
  • Определите, как клиенты и клиентские приложения будут перенаправляться на новый сервер.
  • Задокументируйте прочие зависимости, такие как параметры аудита и оповещения.

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

Отработка отказа в геореплицируемую базу данных-получатель

При использовании активной георепликации и групп автоматической отработки отказа в качестве механизма восстановления можно настроить политику автоматической отработки отказа или использовать незапланированную отработку отказа вручную. После запуска отработка отказа приводит к повышению базы данных-получателя до новой базы данных-источника и делает ее доступной для записи новых транзакций и реагирования на запросы. При этом происходят минимальные потери данных, которые еще не реплицированы. Сведения о разработке процесса отработки отказа см. в статье Проектирование приложения для облачного аварийного восстановления с использованием активной георепликации в базе данных SQL.

Примечание

После возобновления работы центра обработки данных старые базы данных-источники автоматически переподключаются к новым базам данных-источникам и становятся базами данных-получателями. Если базу данных-источник необходимо повторно переместить в исходный регион, вы можете вручную запустить плановую отработку отказа (восстановление размещения).

Процедура геовосстановления

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

Примечание

Если работа центра обработки данных возобновится до переключения приложения на восстановленную базу данных, то можно будет отменить восстановление.

Выполнение задач после восстановления размещения и восстановления

После восстановления посредством любого из механизмов восстановления необходимо выполнить следующие дополнительные задачи, прежде чем данные пользователей и приложений будут заархивированы, а они смогут возобновить работу.

  • Перенаправьте клиенты и клиентские приложения на новый сервер и восстановленную базу данных.
  • Убедитесь, что заданы соответствующие правила брандмауэра для IP-адресов уровня сервера, позволяющие пользователям подключаться к брандмауэрам уровня базы данных или использовать их, чтобы включить соответствующие правила.
  • Убедитесь, что заданы соответствующие имена для входа и разрешения уровня базы данных master (или используйте автономных пользователей).
  • Настройте аудит соответствующим образом.
  • Настройте оповещения соответствующим образом.

Примечание

Если вы используете группу отработки отказа и подключаетесь к базам данных, используя прослушиватель для чтения и записи, после отработки отказа произойдет автоматическое и прозрачное перенаправление в приложение.

Обновление приложения с минимальным простоем

Иногда приложение нужно перевести в автономный режим для планового обслуживания, например, чтобы обновить его. В статье Управление последовательными обновлениями для облачных приложений с помощью активной георепликации базы данных SQL описывается, как с помощью активной георепликации обеспечить последовательное обновление облачного приложения, чтобы свести к минимуму простой при обновлениях и обеспечить путь восстановления, если случится сбой.

Дальнейшие действия

Вопросы разработки приложений для отдельных баз данных и эластичных пулов рассматриваются в статьях Разработка глобально доступных служб с помощью Базы данных SQL Azure и Стратегии аварийного восстановления для приложений с использованием пула эластичных баз данных SQL.