Поделиться через


Высокий уровень доступности в Azure Cosmos DB для виртуального ядра MongoDB

Область применения: Виртуальные ядра MongoDB

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

Все основные сегменты в кластере подготавливаются в одну зону доступности (AZ) для повышения задержки между сегментами. Резервные сегменты подготавливаются в другую зону доступности.

Даже без включения высокой доступности каждый узел имеет собственное локально избыточное хранилище (LRS) с тремя синхронными репликами, поддерживаемыми службой служба хранилища Azure. Все три реплики находятся в регионе Azure кластера. Если произошел сбой одной реплики, служба служба хранилища Azure обнаруживает ее и прозрачно повторно создает сбой реплики. См. метрики на этой странице для обеспечения устойчивости хранилища LRS.

При включении высокой доступности виртуальные ядра Azure Cosmos DB для MongoDB запускают один резервный сегмент для каждого основного сегмента в кластере. Каждый основной и резервный сегмент имеют одинаковую конфигурацию вычислений и хранилища. Основное и резервное использование синхронной репликации. Этот тип репликации позволяет всегда иметь одинаковые данные на основных и резервных сегментах в кластере. В этой оболочке наша служба обнаруживает сбой в основных сегментах и выполняет отработку отказа на резервные узлы с нулевой потерей данных.

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

Высокий уровень доступности можно включить во время создания кластера. Высокий уровень доступности также можно включить и отключить в любое время в существующем кластере виртуальных ядер Azure Cosmos DB для MongoDB. При включении или отключении высокой доступности в кластере виртуальных ядер Azure Cosmos DB для MongoDB отсутствует время простоя базы данных.

Что происходит во время отработки отказа

Отработка отказа каждого сегмента состоит из трех этапов: обнаружение недоступности, переключение на резервный сегмент и повторное создание резервного сегмента. Служба выполняет постоянный мониторинг доступности для каждого основного и резервного сегментов в кластере, выполняя периодическое проверку работоспособности. Когда проверка работоспособности надежно указывает на то, что сегмент стал неответственным и должен быть объявлен сбой, инициируется фактическая отработка отказа (переключение) на резервный сегмент.

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

После завершения отработки отказа сегментов кластер полностью работает. Последний шаг, который необходимо вернуть к исходной конфигурации с высоким уровнем доступности, — повторно создать резервный сегмент. Это резервное повторное создание сегмента выполняется без простоя или влияния производительности на основной сегмент.