Выполнение детализации аварийного восстановления — Управляемый экземпляр SQL Azure

Область применения: Управляемый экземпляр SQL Azure

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

Этапы отработки аварийного восстановления:

• моделирование сбоя уровня данных;
• восстановление;
• проверка целостности приложения после восстановления.

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

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

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

Моделирование сбоя

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

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

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

Проверка

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

Группы отработки отказа

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

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

Моделирование сбоя

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

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

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

Проверка

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

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

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

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