Руководство по аварийному восстановлению — База данных SQL Azure

  • Статья

Применимо к:База данных SQL Azure

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

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

Простой службы

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

  • баннер портал Azure

    Если ваша подписка определена как затронутая, в портал Azure уведомлениях возникает сбой службы:

    A screenshot from the Azure portal of a notification of an Azure SQL Database service issue.

  • Справка и поддержка и поддержка + устранение неполадок

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

    A screenshot of the Help+Support page showing a notification of an active service health issue..

  • Работоспособность служб

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

    A screenshot of the Azure portal Service Health page during a service issue in Southeast Asia, showing the Issue and a map of affected resources.

  • Уведомление по электронной почте

    Если вы настроили оповещения, уведомление по электронной почте отправляется, azure-noreply@microsoft.com когда сбой службы влияет на подписку и ресурс. Текст сообщения электронной почты обычно начинается с "Оповещение журнала действий ... была вызвана проблемой службы для подписки Azure...". Дополнительные сведения о оповещениях о работоспособности служб см. в статье "Получение оповещений журнала действий" в уведомлениях службы Azure с помощью портал Azure.

Когда следует инициировать аварийное восстановление во время сбоя

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

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

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

Инструкции по восстановлению после сбоя

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

Отработка отказа (без потери данных) на гео-реплика сервер-получатель

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

Примечание.

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

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

Технология Способ Шаги
активная георепликация; PowerShell Отработка отказа на вторичную гео реплика с помощью PowerShell
T-SQL Отработка отказа на вторичную гео реплика с помощью T-SQL
Группы отработки отказа Azure CLI Отработка отказа на дополнительный сервер с помощью Azure CLI
Портал Azure Отработка отказа на дополнительный сервер через портал Azure
PowerShell Отработка отказа на дополнительный сервер с помощью PowerShell

Принудительное отработка отказа (потенциальная потеря данных) на гео-реплика сервер-получатель

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

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

Технология Способ Шаги
активная георепликация; Azure CLI Принудительная отработка отказа на вторичную гео реплика tion через Azure CLI
Портал Azure Принудительная отработка отказа на вторичную гео реплика через портал Azure
PowerShell Принудительная отработка отказа на вторичную геоизбыточное реплика с помощью PowerShell
T-SQL Принудительная отработка отказа на вторичную гео реплика tion через T-SQL
Группы отработки отказа Портал Azure Принудительная отработка отказа на дополнительный сервер через портал Azure но выберите принудительное отработка отказа.
Azure CLI Принудительная отработка отказа на дополнительный сервер через Azure CLI , но используйте --allow-data-loss
PowerShell Принудительная отработка отказа на дополнительный сервер с помощью PowerShell , но использование -AllowDataLoss

Геовосстановление

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

Дополнительные сведения о геовосстановление с помощью Azure CLI, портал Azure, PowerShell или REST API см. в разделе геовосстановление База данных SQL Azure.

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

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

Важно!

Рекомендуется проводить периодические детализации стратегии аварийного восстановления для проверки отказоустойчивости приложений, а также всех операционных аспектов процедуры восстановления. Для других слоев инфраструктуры приложений может потребоваться перенастройка. Дополнительные сведения об устойчивых шагах архитектуры см. в списке проверка База данных SQL Azure высокого уровня доступности и аварийного восстановления.

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

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

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

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

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

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

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

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

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

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

Следующие шаги