Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье содержатся подробные сведения о региональной устойчивости с зонами доступности и аварийного восстановления между регионами и непрерывности бизнес-процессов для Azure DocumentDB.
Общие сведения об архитектуре надежности в Azure см. в статье "Надежность Azure".
Поддержка зоны доступности
Зоны доступности — это физически отдельные группы центров обработки данных в регионе Azure. При сбое одной зоны службы могут переключиться на одну из оставшихся зон.
Чтобы получить поддержку зоны доступности, необходимо включить высокий уровень доступности (HA).
Высокая доступность (HA) позволяет избежать простоя базы данных, сохраняя резервные реплики каждого шарда в кластере. Если сегмент выходит из строя, Azure DocumentDB переключает входящие подключения из неудачного сегмента на резервную реплику.
Если высокий уровень доступности включен в регионе, поддерживающем зоны доступности, сегменты реплики высокой доступности подготавливаются в другой зоне доступности, отличной от основных сегментов. HA-реплики не принимают запросы от клиентов, если основной сегмент не прекращает работу.
Если высокий уровень доступности отключен, каждый сегмент имеет собственное локально избыточное хранилище (LRS) с тремя синхронными репликами, поддерживаемыми службой хранилища Azure. Если произошел сбой одной реплики, служба хранилища Azure обнаруживает это и автоматически воссоздает соответствующие данные. Сведения об устойчивости хранилища LRS см. в разделе "Сводка параметров избыточности". Однако если регион выходит из строя, вы рискуете значительным простоем и возможной потерей данных.
Создание ресурса с включенными зонами доступности
Чтобы включить зоны доступности, необходимо включить высокий уровень доступности при создании кластера или в разделе масштабирования существующего кластера на портале Azure.
Аварийное восстановление между регионами и непрерывность бизнес-процессов
Аварийное восстановление (DR) относится к процедурам, которые организации используют для восстановления после событий значительного воздействия, таких как стихийные бедствия или ошибочные развертывания, которые приводят к простою и потере данных. Независимо от причины, лучшее средство для аварийного восстановления является хорошо определенным и проверенным планом аварийного восстановления и проектом приложения, который активно поддерживает аварийное восстановление. Прежде чем приступить к созданию плана аварийного восстановления, ознакомьтесь с рекомендациями по разработке стратегии аварийного восстановления.
Для восстановления после сбоя компания Microsoft использует модель общей ответственности. В этой модели корпорация Майкрософт гарантирует, что доступны базовые инфраструктуры и службы платформы. Однако многие службы Azure не делают автоматической репликации данных и не обеспечивают возврат из вышедшего из строя региона для перекрестной репликации в другой доступный регион. Для этих сервисов вы отвечаете за настройку плана аварийного восстановления, соответствующего вашей рабочей нагрузке. Большинство служб, работающих на платформе Azure как услуга (PaaS), предоставляют функции и рекомендации для поддержки аварийного восстановления. Вы можете использовать специализированные функции для поддержки быстрого восстановления и разработки плана аварийного восстановления.
Azure DocumentDB не обеспечивает встроенные функции автоматизированной отработки отказа и аварийного восстановления. Планирование высокого уровня доступности является критически важным шагом по мере масштабирования решения.
Аварийное восстановление в единственном географическом регионе
Чтобы максимально повысить время работы, заранее спланируйте обеспечение непрерывности бизнес-процессов и подготовьтесь к аварийному восстановлению с помощью Azure DocumentDB.
Хотя службы Azure предназначены для повышения времени простоя, могут возникнуть незапланированные сбои служб. План аварийного восстановления гарантирует наличие стратегии для обработки сбоев региональных служб.
Azure DocumentDB автоматически создает резервные копии данных через регулярные интервалы. Автоматическое резервное копирование выполняется без влияния на производительность или доступность операций базы данных. Все резервные копии выполняются автоматически в фоновом режиме и хранятся отдельно от исходных данных в службе хранилища. Эти автоматические резервные копии полезны в сценариях при случайном удалении или изменении ресурсов, а затем требуют исходных версий.
Автоматические резервные копии сохраняются в различных интервалах на основе того, активен ли кластер в настоящее время или недавно удален.
| Период хранения | |
|---|---|
| Активные кластеры |
35 дней |
| Удаленные кластеры |
7 дней |
Проектирование высокого уровня доступности
Высокий уровень доступности (HA) должен быть включен для критически важных кластеров Azure DocumentDB, выполняющих рабочие нагрузки рабочей среды. В кластере с поддержкой высокой доступности каждый сегмент служит основным сегментом, а также сегментом горячего ожидания, подготовленным в другой зоне доступности. Репликация между первичным и вторичным сегментом синхронна по умолчанию. Любое изменение базы данных сохраняется как на сегментах-источнике, так и на вторичных (горячих резервных) сегментах перед получением ответа от базы данных.
Служба поддерживает проверки работоспособности и пульса для каждого первичного и вторичного фрагмента кластера. Если первичный шард становится недоступным из-за сбоя в зоне или регионе, вторичный шард автоматически продвигается, становясь новым первичным, а для нового первичного создается новый вторичный шард. Кроме того, если вторичный сегмент становится недоступным, служба автоматически создает новый вторичный сегмент с полной копией данных из первичного.
Если служба активирует переключение на резервный шард с первичного на вторичный, подключения незаметно перенаправляются на новый первичный шард.
Синхронная репликация между основными и вторичными шардами гарантирует отсутствие потери данных в случае отказоустойчивости.
Дальнейшие шаги
- Дополнительные сведения о совместимости функций с MongoDB.
- Изучение параметров миграции из MongoDB в Azure DocumentDB
- Начало работы с созданием учетной записи.