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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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