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

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

• База данных SQL Azure
• Управляемый экземпляр SQL Azure

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

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

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

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

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

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

  

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

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

  

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

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

  

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

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

• Метрика доступности

  Вы можете отслеживать и настраивать оповещения метрики доступности База данных SQL 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	Принудительная отработка отказа на вторичную георепликацию через Azure CLI
	Портал Azure	Принудительное переход на вторичный георепликации через портал Azure
	PowerShell	Принудительная отработка отказа на вторичную георепликацию с помощью PowerShell
	T-SQL	Принудительная отработка отказа на вторичную георепликацию через 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 высокой доступности и аварийного восстановления.

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

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

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

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

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

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

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

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

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

Если на первичном сервере настроен аудит, сделайте его идентичным на сервере-получателе. Дополнительные сведения см. в разделе "Аудит".

Связанный контент

Дополнительные сведения см. в следующих статьях:

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