Переключение

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

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

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

После переключения топология становится:

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

Когда использовать переключение

Используйте переключение, когда:

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

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

Перед началом работы

Перед началом работы проверьте следующее:

• Оба кластера доступны.
• Репликация CDC работает нормально.
• Задержка CDC достаточно мала для целевого времени восстановления.
• Запись приложений можно приостановить или повторить во время смены роли.
• Вы подготовили конфигурацию новой топологии.

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

Постройте новую топологию

Создайте конфигурацию полной замены, в которой cluster-b станет источником, а cluster-a - целью.

# If you followed Set Up CDC Replication, cluster A is the original source cluster,
# and cluster B is the original target cluster.
cluster_a_id = source_cluster_id
cluster_a_addr = source_cluster_addr
cluster_a_client_addr = source_client_addr
cluster_a_token = source_cluster_token
cluster_a_pchannels = source_cluster_pchannels

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

switchover_config = {
    "clusters": [
        {
            "cluster_id": cluster_a_id,
            "connection_param": {
                "uri": cluster_a_addr,
                "token": cluster_a_token,
            },
            "pchannels": cluster_a_pchannels,
        },
        {
            "cluster_id": cluster_b_id,
            "connection_param": {
                "uri": cluster_b_addr,
                "token": cluster_b_token,
            },
            "pchannels": cluster_b_pchannels,
        },
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": cluster_b_id,
            "target_cluster_id": cluster_a_id,
        }
    ],
}

Примените новую топологию

Примените одну и ту же конфигурацию к обоим кластерам. Сначала отправьте запрос на текущий основной кластер, а затем отправьте его на резервный. Если вы позже переключитесь обратно, измените порядок, поскольку cluster-b является текущим основным.

from pymilvus import MilvusClient

client_a = MilvusClient(uri=cluster_a_client_addr, token=cluster_a_token)
client_b = MilvusClient(uri=cluster_b_client_addr, token=cluster_b_token)

try:
    client_a.update_replicate_configuration(**switchover_config)
    client_b.update_replicate_configuration(**switchover_config)
finally:
    client_a.close()
    client_b.close()

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

Если запрос не выполняется из-за временной ошибки сети или службы, повторите попытку с той же конфигурацией.

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

После того как cluster-b станет первичным:

1. Направьте трафик записи на cluster-b.
2. Убедитесь, что чтение и запись проходят успешно на cluster-b.
3. Убедитесь, что cluster-a больше не получает записи приложений.
4. Продолжайте следить за репликацией с cluster-b на cluster-a.

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

Убедитесь, что cluster-b выполняет функции нового основного сервера и что данные остаются согласованными. Общие проверки включают:

• Сравните количество строк для важных коллекций.
• Запросите известные первичные ключи из обоих кластеров.
• Выполните репрезентативный поиск на новом основном и старом резервном кластерах.
• Выполните небольшую запись на cluster-b и убедитесь, что она реплицируется на cluster-a.

Переключение обратно

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

cluster-a -> cluster-b

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

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

При переключении теряются данные?

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

Нужно ли останавливать запись приложений?

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

Почему переключение занимает больше времени, чем ожидалось?

Наиболее распространенной причиной является задержка CDC. Новый основной сервер должен получить оставшиеся данные, прежде чем он сможет безопасно переключиться с RPO = 0.

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

Да. Повторите запрос с той же целевой топологией.

Что происходит со старым основным сервером?

Старый основной сервер становится резервным. Он больше не должен получать записи приложений.