Восстановление базы данных SQL Azure или отработка отказа на базу данных-получатель

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

База данных SQL Azure предоставляет следующие возможности восстановления после сбоя:

Чтобы узнать о сценариях непрерывности бизнес-процессов и функциях, которые их обеспечивают, ознакомьтесь с непрерывностью бизнес-процессов.

Примечание

При использовании избыточных между зонами пулов и баз данных уровня "Премиум"или "Критически важный для бизнеса" процесс восстановления автоматизирован. Поэтому описанные в этой статье действия выполнять не нужно.

База данных-источник и база данных-получатель должны иметь один и тот же уровень служб. Кроме того, настоятельно рекомендуем создавать базу данных-источник и базу данных-получатель с одинаковым объемом вычислительных ресурсов (DTU или виртуальных ядер). Дополнительные сведения см. в разделе Повышение или понижение уровня базы данных-источника.

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

Подготовка к событию сбоя

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

  • Определите сервер в другом регионе, который станет новым сервером-источником. При использовании геовосстановления обычно это сервер в сопряженном регионе того региона, в котором расположена база данных. Это исключает дополнительные затраты на трафик во время операций геовосстановления.
  • Идентифицируйте и при необходимости определите правила брандмауэра для IP-адресов уровня сервера, необходимые пользователям для доступа к новой базе данных-источнику.
  • Определите, как пользователи будут перенаправляться к новому серверу-источнику: например, изменяя строки подключения или записи DNS.
  • Определите и при необходимости создайте имена для входа, которые должны присутствовать в базе данных master на новом сервере-источнике, и убедитесь, что эти имена для входа имеют соответствующие разрешения в базе данных master, если таковые имеются. Дополнительные сведения см. в разделе Как управлять безопасностью базы данных SQL после аварийного восстановления.
  • Определите правила генерации оповещений, которые потребуется обновить для сопоставления с новой базой данных-источником.
  • Задокументируйте конфигурацию аудита текущей базы данных-источника.
  • Выполните отработку аварийного восстановления. Чтобы сымитировать сбой для географического восстановления, можно удалить или переименовать исходную базу данных, что приведет к сбою подключения приложения. Чтобы сымитировать сбой с помощью групп отработки отказа, отключите веб-приложение или виртуальную машину, подключенную к базе данных, или отработку отказа базы данных, чтобы вызвать сбой подключения приложения.

Время начала восстановления

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

  1. Постоянная ошибка подключения из уровня приложения к базе данных.
  2. На портале Azure отображается оповещение о происшествии с большой степенью воздействия в регионе.

Примечание

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

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

Для получения последней геореплицированной точки восстановления используйте операцию получения восстанавливаемой базы данных (LastAvailableBackupDate).

Ожидание восстановления служб

Группы Azure прилагают все усилия для максимально быстрого восстановления работоспособности служб, но в зависимости от причины это может занимать часы и даже дни. Если длительный простой некритичен для вашего приложения, вы можете просто дождаться завершения восстановления. В этом случае вам не нужно предпринимать какие-либо действия. Текущее состояние служб можно просмотреть на панели мониторинга работоспособности служб Azure. После восстановления региона ваше приложение снова станет доступным.

Отработка отказа на геореплицированный сервер-получатель в группе отработки отказа

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

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

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

Восстановление с использованием геовосстановления

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

Настройка базы данных после восстановления

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

Обновление строк подключения

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

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

Настройка правил брандмауэра

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

Настройка учетных данных и пользователей базы данных

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

Примечание

Необходимо настроить и протестировать правила брандмауэра и имена для входа (и их разрешения) на сервере во время отработки аварийного восстановления. Эти объекты уровня сервера и их конфигурации могут быть недоступны во время сбоя.

Настройка оповещений телеметрии

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

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

Включение аудита

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

Примечание

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

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