Руководство по аварийному восстановлению — Управляемый экземпляр 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.
Когда следует инициировать аварийное восстановление во время сбоя
В случае сбоя службы, влияющего на ресурсы приложения, рассмотрите следующие курсы действий:
Команды Azure старательно работают над восстановлением доступности службы как можно быстрее, но в зависимости от первопричины иногда может занять несколько часов. Если приложение может терпеть значительное время простоя, вы можете просто ждать завершения восстановления. В этом случае вам не нужно предпринимать какие-либо действия. Просмотрите работоспособность отдельных ресурсов на странице работоспособности ресурсов любого ресурса в меню справки. Ознакомьтесь со страницей работоспособности ресурсов для обновлений и последними сведениями о сбое. После восстановления региона ваше приложение снова станет доступным.
Восстановление в другом регионе Azure может потребовать изменения строка подключения приложений или перенаправления DNS и может привести к постоянной потере данных. Поэтому аварийное восстановление должно выполняться только в том случае, если длительность сбоя приближается к целевой цели времени восстановления приложения (RTO). При развертывании приложения в рабочей среде следует выполнять регулярный мониторинг работоспособности приложения и утверждать, что восстановление гарантируется только в том случае, если на уровне приложения к базе данных произошел длительный сбой подключения. В зависимости от допустимости приложений к простою и возможной бизнес-ответственности вы можете решить, нужно ли ждать восстановления службы или инициировать аварийное восстановление самостоятельно.
Инструкции по восстановлению после сбоя
Если Управляемый экземпляр SQL Azure сбоя в регионе не было устранено в течение длительного периода времени и влияет на соглашение об уровне обслуживания вашего приложения, рассмотрите следующие действия.
Отработка отказа (без потери данных) на геореплицированный вторичный экземпляр
Если группы отработки отказа включены, проверьте, находится ли состояние ресурса первичного и вторичного экземпляра в портал Azure. В этом случае плоскость данных для первичного и вторичного экземпляра является работоспособным.
Запуск отработки отказа групп отработки отказа в дополнительный регион с помощью:
Примечание.
Отработка отказа требует полной синхронизации данных перед переключением ролей и не приводит к потере данных. В зависимости от типа сбоя службы нет гарантии, что отработка отказа без потери данных будет выполнена успешно, но стоит попробовать в качестве первого варианта восстановления.
Принудительное отработка отказа (потенциальная потеря данных) на геореплицированный вторичный экземпляр
Если отработка отказа не завершается корректно и возникает ошибка, или если состояние базы данных-источника не подключено к Сети, тщательно рассмотрите возможность принудительной отработки отказа с потенциальной потерей данных в дополнительный регион.
Чтобы инициировать принудительное отработка отказа, используйте:
- портал Azure но выберите вариант принудительной отработки отказа.
- PowerShell , но используйте
--allow-data-loss. - Azure CLI , но используйте
-AllowDataLoss.
Геовосстановление
Если вы не включили группы отработки отказа, то в качестве последнего способа можно использовать геовосстановление для восстановления после сбоя. Геовосстановление использует геореплицированные резервные копии в качестве источника. Базу данных можно восстановить в любом экземпляре в любом регионе Azure из последних геореплицированных резервных копий. Вы можете запросить геовосстановление, даже если сбой сделал экземпляр или весь регион недоступным.
Дополнительные сведения о геовосстановление с помощью Azure CLI, портал Azure, PowerShell или REST API см. в разделе "Геовосстановление".
Настройка базы данных после восстановления
Если вы используете геоработку отказа или геовосстановление для восстановления после сбоя, необходимо убедиться, что подключение к новому экземпляру настроено правильно, чтобы нормальная функция приложения была возобновлена. Ниже приведен контрольный список задач для подготовки восстановленной базы данных к использованию в рабочей среде.
Внимание
Рекомендуется проводить периодические детализации стратегии аварийного восстановления для проверки отказоустойчивости приложений, а также всех операционных аспектов процедуры восстановления. Для других слоев инфраструктуры приложений может потребоваться перенастройка. Дополнительные сведения о шагах устойчивой архитектуры см . в контрольном списке высокого уровня доступности и аварийного восстановления.
Обновление строк подключения
- Если вы используете геовосстановление, необходимо убедиться, что подключение к новому экземпляру настроено правильно, чтобы нормальная функция приложения была возобновлена. Так как восстановленная база данных находится в другом экземпляре, необходимо обновить строка подключения приложения, чтобы указать на этот сервер. Дополнительные сведения об изменении строк подключения см. в разделе о соответствующем языке разработки для своей библиотеки подключений.
- Если вы используете группы отработки отказа для восстановления после сбоя и используете прослушиватели только для чтения и чтения в приложениях строка подключения, дальнейшие действия не требуются, так как подключения автоматически направляются в новый первичный сервер.
Настройка правил брандмауэра
Убедитесь, что правила группы безопасности сети и таблицы маршрутов, настроенные для дополнительного экземпляра, соответствуют заданным в основном экземпляре. Ознакомьтесь с конфигурацией подсети , помогающей службам, чтобы узнать больше.
Настройка учетных данных и пользователей базы данных
Создайте имена входа, которые должны присутствовать в master базе данных на вторичном экземпляре, и убедитесь, что эти имена входа имеют соответствующие разрешения в master базе данных, если таковые имеются.
Настройка оповещений телеметрии
Убедитесь, что существующие параметры правила генерации оповещений обновлены для сопоставления с новым основным экземпляром. Подробнее о правилах генерации оповещений базы данных см. в разделах Получение уведомлений об оповещениях и Получение информации о работоспособности службы.
Включение аудита
Если аудит настроен на основном экземпляре, сделайте его идентичным в дополнительном экземпляре. Дополнительные сведения см. в статье "Аудит SQL Azure" для Управляемый экземпляр SQL Azure.
Связанный контент
Дополнительные сведения см. в следующих статьях:
- Сценарии непрерывности.
- Автоматическое резервное копирование
- Восстановите базу данных из резервных копий, инициированных службой.
- Группы отработки отказа.
- Руководство по аварийному восстановлению
- Контрольный список высокого уровня доступности и аварийного восстановления.
- Базы данных, избыточные между зонами