Обход отказа

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

В данном руководстве предполагается исходная топология:

cluster-a (primary)  ->  cluster-b (standby)

После обхода отказа cluster-b становится автономной основной:

cluster-b (primary)

Когда использовать обход отказа

Используйте обход отказа только в следующих случаях:

• Оригинальный основной сервер не может отвечать на запросы.
• Первичная система не может быть восстановлена в течение приемлемого времени.
• Восстановление доступности записи важнее, чем ожидание старого основного сервера.

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

Риск потери данных

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

Возможная потеря данных определяется задержкой CDC на момент, когда первичная система стала недоступной.

Прежде чем запускать обход отказа, поймите, чем это чревато:

Цель	Переключение	Обход отказа
Восстановление записи при недоступности основной системы	Нет	Да
Избежать потери данных	Да	Не гарантируется
Требуется, чтобы старая основная система отреагировала	Да	Нет

Прежде чем начать

Убедитесь в следующем:

• Оригинальный основной сервер недоступен.
• Вы решили не ждать восстановления основной системы.
• Трафик приложений можно перенаправить на резервную систему.
• Автоматизация трафика не будет отправлять записи обратно на старый основной кластер, если он восстановится.
• У вас есть идентификатор резервного кластера, адрес, токен и pchannels.

Самое важное требование безопасности - предотвратить раздвоение мозга. После обхода отказа только восстановленный резервный кластер должен принимать записи приложений.

Постройте конфигурацию обхода отказа

Создайте конфигурацию, содержащую только резервный кластер и не имеющую топологии репликации. Установите force_promote=True.

# If you followed Set Up CDC Replication, cluster B is the original target cluster.
cluster_b_id = target_cluster_id
cluster_b_addr = target_cluster_addr
cluster_b_client_addr = target_client_addr
cluster_b_token = target_cluster_token
cluster_b_pchannels = target_cluster_pchannels

failover_config = {
    "clusters": [
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        }
    ],
    "cross_cluster_topology": [],
    "force_promote": True,
}

Продвижение резервного кластера

Отправьте запрос на резервный кластер.

from pymilvus import MilvusClient

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.update_replicate_configuration(**failover_config)
finally:
    client_b.close()

Если запрос успешен, cluster-b становится автономным основным и может принимать записи.

Перенаправление трафика приложений

После продвижения:

1. Перенаправьте трафик записи на cluster-b.
2. Удалите cluster-a из конечных точек записи, балансировщиков нагрузки, записей DNS и автоматизации.
3. Убедитесь, что cluster-b принимает записи.
4. Сохраняйте cluster-a изолированным до тех пор, пока он не будет выведен из эксплуатации или явно перестроен.

Пример проверки записи:

client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_b.insert(
        collection_name="test_collection",
        data=[{"id": 1, "vector": [0.1] * 128}],
    )
finally:
    client_b.close()

Отрегулируйте поля "Имя коллекции" и "Схема" в соответствии с вашим развертыванием.

Проверка результата

Проверьте продвигаемый кластер напрямую:

• Записи проходят успешно на cluster-b.
• Чтение возвращает ожидаемые данные.
• Ни один компонент приложения не пишет на cluster-a.

Работа со старой основной системой

После обхода отказа считайте cluster-a устаревшим. Не отправляйте на него записи приложений, если он снова станет доступным. Он может содержать данные, которые никогда не реплицировались на cluster-b, а cluster-b может уже содержать новые записи после обхода отказа.

Не подключайте cluster-a к старой топологии автоматически. Восстановление старой основной топологии - это отдельная задача восстановления, которая должна быть тщательно спланирована.

Минимизация потери данных

Нельзя полностью исключить риск потери данных при обходе отказа, но его можно снизить:

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

ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ

Всегда ли при обходе отказа теряются данные?

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

Сколько времени занимает обход отказа?

Обычно оно завершается в течение нескольких секунд, в зависимости от состояния кластера и доступности плоскости управления на резервном сервере.

Можно ли запустить обход отказа на основном сервере?

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

Может ли старый основной кластер подключиться автоматически?

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

Как избежать "раздвоения мозга"?

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