Home
Blog
Высокая доступность базы данных Vector: как построить резервный кластер Milvus с CDC

Высокая доступность базы данных Vector: как построить резервный кластер Milvus с CDC

Tutorials

March 26, 2026

Cal Huang

Каждой производственной базе данных необходим план действий на случай, если что-то пойдет не так. Реляционные базы данных уже несколько десятилетий имеют WAL shipping, binlog replication и автоматическое восстановление после сбоев. Но векторные базы данных - несмотря на то, что они стали основной инфраструктурой для приложений искусственного интеллекта - все еще находятся в процессе становления. Большинство из них в лучшем случае предлагают избыточность на уровне узлов. Если весь кластер выходит из строя, вы восстанавливаетесь из резервных копий и перестраиваете векторные индексы с нуля - процесс, который может занять несколько часов и обойтись в тысячи вычислений, поскольку регенерация вкраплений с помощью ML-конвейера стоит недешево.

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

В этом руководстве рассматриваются две вещи: стратегии высокой доступности, доступные для векторных баз данных (чтобы вы могли оценить, что на самом деле означает "готовность к производству"), и практическое руководство по настройке первичной и резервной репликации Milvus CDC с нуля.

Это первая часть цикла:

Часть 1 (эта статья): Настройка первичной и резервной репликации на новых кластерах

Часть 2: Добавление CDC в существующий кластер, в котором уже есть данные, с помощью Milvus Backup

Часть 3: Управление обходом отказа - продвижение резервного кластера, когда основной выходит из строя

Почему высокая доступность важнее для векторных баз данных?

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

Векторные базы данных хранят вкрапления - плотные числовые представления, генерируемые ML-моделями. Их восстановление означает повторное прохождение всего набора данных через конвейер встраивания: загрузка сырых документов, их разбивка на части, вызов модели встраивания и повторная индексация. Для набора данных с сотнями миллионов векторов это может занять несколько дней и обойтись в тысячи долларов на вычислениях на GPU.

Тем временем системы, зависящие от векторного поиска, часто оказываются на критическом пути:

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

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

Как выглядит высокая доступность производственного уровня для векторной базы данных?

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

Слой	От чего защищает	Как работает	Время восстановления	Потеря данных
Уровень узла (мультирепликация)	Авария одного узла, аппаратный сбой, повреждение OOM, отказ AZ.	Копирование одних и тех же сегментов данных на нескольких узлах; другие узлы принимают нагрузку на себя	Мгновенно	Ноль
Уровень кластера (репликация CDC)	Весь кластер выходит из строя - неудачное развертывание K8s, удаление пространства имен, повреждение хранилища	Потоковая передача каждой записи на резервный кластер через журнал Write-Ahead Log; резервный кластер всегда отстает на несколько секунд	Минуты	Секунды
Подстраховка (периодическое резервное копирование)	Катастрофическое повреждение данных, выкупное ПО, человеческая ошибка, распространяющаяся через репликацию.	Периодически делает моментальные снимки и хранит их в отдельном месте	Часы	Часы (с момента последнего резервного копирования)

Эти уровни дополняют друг друга, а не являются альтернативой. В производственном развертывании они должны сочетаться:

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

Оценивая векторные базы данных, спросите: какие из этих трех уровней продукт действительно поддерживает? Большинство векторных баз данных сегодня предлагают только первый. Milvus поддерживает все три, причем CDC является встроенной функцией, а не сторонним дополнением.

Что такое Milvus CDC и как он работает?

Milvus CDC (Change Data Capture) - это встроенная функция репликации, которая считывает журнал записи-восстановления (WAL) основного кластера и передает каждую запись на отдельный резервный кластер. Резервный кластер воспроизводит записи и в итоге получает те же самые данные, обычно на несколько секунд позже.

Эта схема хорошо известна в мире баз данных. В MySQL есть репликация binlog. В PostgreSQL есть доставка WAL. В MongoDB используется репликация на основе oplog. Это проверенные методы, которые поддерживают реляционные и документальные базы данных в рабочем состоянии на протяжении десятилетий. Milvus предлагает тот же подход к векторным рабочим нагрузкам - это первая крупная векторная база данных, предлагающая репликацию на основе WAL в качестве встроенной функции.

Три свойства делают CDC подходящей для аварийного восстановления:

Синхронизация с низкой задержкой. CDC передает операции по мере их выполнения, а не запланированными партиями. В нормальных условиях резервная копия отстает от основной на несколько секунд.
Упорядоченное воспроизведение. Операции поступают в резервную систему в том же порядке, в каком они были записаны. Данные остаются неизменными без выверки.
Восстановление контрольной точки. Если процесс CDC терпит крах или падает сеть, он возобновляет работу с того места, на котором остановился. Данные не пропускаются и не дублируются.

Как работает архитектура CDC?

Развертывание CDC состоит из трех компонентов:

CDC architecture showing Source Cluster with Streaming Nodes and CDC Nodes consuming the WAL, replicating data to the Target Cluster's Proxy layer, which forwards DDL/DCL/DML operations to Streaming Nodes and appends to WAL Архитектура CDC, показывающая исходный кластер с потоковыми узлами и узлами CDC, потребляющими WAL, реплицирующими данные на прокси-уровень целевого кластера, который передает операции DDL/DCL/DML потоковым узлам и добавляет их в WAL

Компонент	Роль
Основной кластер	Производственный экземпляр Milvus. Все чтения и записи происходят здесь. Каждая запись записывается в WAL.
Узел CDC	Фоновый процесс рядом с основным. Считывает записи WAL и пересылает их резервному. Работает независимо от пути чтения/записи - не влияет на производительность запросов и вставок.
Резервный кластер	Отдельный экземпляр Milvus, который воспроизводит переданные записи WAL. Хранит те же данные, что и основной, с секундной задержкой. Может обслуживать запросы на чтение, но не принимает записи.

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

Учебное пособие: Настройка резервного кластера Milvus CDC

Остальная часть этой статьи представляет собой практическое руководство. К концу статьи у вас будет два работающих кластера Milvus с репликацией между ними в режиме реального времени.

Предварительные условия

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

Milvus v2.6.6 или более поздняя версия. CDC требует эту версию. Рекомендуется последняя версия патча 2.6.x.
Milvus Operator v1.3.4 или более поздней версии. В этом руководстве Оператор используется для управления кластером Kubernetes.
Работающий кластер Kubernetes с настроенными kubectl и helm.
Python с pymilvus для шага настройки репликации.

Два ограничения в текущем выпуске:

Ограничение	Подробности
Одна реплика CDC	Одна реплика CDC на кластер. Распределенный CDC планируется в будущем выпуске.
Нет BulkInsert	BulkInsert не поддерживается при включенном CDC. Также планируется к выпуску в будущем.

Шаг 1: Обновление Milvus Operator

Обновите Milvus Operator до версии 1.3.4 или более поздней:

helm repo add zilliztech-milvus-operator https://zilliztech.github.io/milvus-operator/
# "zilliztech-milvus-operator" has been added to your repositories
helm repo update zilliztech-milvus-operator
# Hang tight while we grab the latest from your chart repositories…
# …Successfully got an update from the “zilliztech-milvus-operator” chart repository
# Update Complete. ⎈Happy Helming!⎈
helm -n milvus-operator upgrade milvus-operator zilliztech-milvus-operator/milvus-operator
# Release “milvus-operator” has been upgraded. Happy Helming!
# NAME: milvus-operator
# LAST DEPLOYED: Wed Dec  3 17:25:28 2025
# NAMESPACE: milvus-operator
# STATUS: deployed
# REVISION: 30
# TEST SUITE: None
# NOTES:
# Milvus Operator Is Starting, use kubectl get -n milvus-operator deploy/milvus-operator to check if its successfully installed
# Full Installation doc can be found in https://github.com/zilliztech/milvus-operator/blob/main/docs/installation/installation.md
# Quick start with kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_minimum.yaml
# More samples can be found in https://github.com/zilliztech/milvus-operator/tree/main/config/samples
# CRD Documentation can be found in https://github.com/zilliztech/milvus-operator/tree/main/docs/CRD
# Administration Documentation can be found in https://github.com/zilliztech/milvus-operator/tree/main/docs/administration

Убедитесь, что операторская капсула запущена:

kubectl get pods -n milvus-operator
# NAME                             READY   STATUS    RESTARTS   AGE
# milvus-operator-9fc99f88-h2hwz   1/1     Running   0          54s

Шаг 2: Развертывание первичного кластера

Создайте YAML-файл для первичного (исходного) кластера. Раздел cdc в разделе components указывает оператору развернуть CDC-узел рядом с кластером:

# This is a sample to deploy a milvus cluster with cdc.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: source-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: cluster
  components:
    image: milvusdb/milvus:v2.6.6 # Use version 2.6.6 or above, as CDC is available from 2.6.6 onwards
    cdc:
      replicas: 1  # Currently, CDC only supports 1 replica
  dependencies:
    msgStreamType: woodpecker

Настройка msgStreamType: woodpecker использует встроенный в Milvus Woodpecker WAL вместо внешней очереди сообщений, такой как Kafka или Pulsar. Woodpecker - это облачный нативный журнал с опережающей записью, представленный в Milvus 2.6, который устраняет необходимость во внешней инфраструктуре обмена сообщениями.

Примените конфигурацию:

kubectl create namespace milvus
# namespace/milvus created
kubectl apply -f milvus_source_cluster.yaml
# milvus.milvus.io/source-cluster created

Дождитесь, пока все стручки достигнут статуса Running. Убедитесь, что стручок CDC работает:

kubectl get pods -n milvus
# Look for source-cluster-milvus-cdc-xxx in Running state
# NAME                                                READY   STATUS    RESTARTS   AGE
# source-cluster-milvus-cdc-66d64747bd-sckxj          1/1     Running   0          2m42s
# source-cluster-milvus-datanode-85f9f56fd-qgbzq       1/1     Running   0          2m42s
# ...

Шаг 3: Развертывание резервного кластера

Резервный (целевой) кластер использует ту же версию Milvus, но не включает компонент CDC - он только получает реплицированные данные:

# This is a sample to deploy a milvus cluster with cdc.
apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: target-cluster
  namespace: milvus
  labels:
    app: milvus
spec:
  mode: cluster
  components:
    image: milvusdb/milvus:v2.6.6 # Use version 2.6.6 or above, as CDC is available from 2.6.6 onwards
  dependencies:
    msgStreamType: woodpecker

Применить:

kubectl apply -f milvus_target_cluster.yaml
# milvus.milvus.io/target-cluster created

Убедитесь, что все стручки запущены:

kubectl get pods -n milvus
# NAME                                                   READY   STATUS    RESTARTS   AGE
# ...
# target-cluster-milvus-datanode-7ffc8cdb6b-xhzcd        1/1     Running   0          104m
# target-cluster-milvus-mixcoord-8649b87c98-btk7m        1/1     Running   0          104m
# ...

Шаг 4: Настройте отношения репликации

Когда оба кластера запущены, настройте топологию репликации с помощью Python с pymilvus.

Определите детали соединения кластеров и имена физических каналов (pchannel):

source_cluster_addr = "http://10.98.124.90:19530" # example address — replace with your actual Milvus server address
target_cluster_addr = "http://10.109.234.172:19530"
source_cluster_token = "root:Milvus"
target_cluster_token = "root:Milvus"
source_cluster_id = "source-cluster"
target_cluster_id = "target-cluster"
pchannel_num = 16
source_cluster_pchannels = []
target_cluster_pchannels = []
for i in range(pchannel_num):
source_cluster_pchannels.append(f"{source_cluster_id}-rootcoord-dml_{i}")
target_cluster_pchannels.append(f"{target_cluster_id}-rootcoord-dml_{i}")

Создайте конфигурацию репликации:

config = {
    "clusters": [
        {
            "cluster_id": source_cluster_id,
            "connection_param": {
                "uri": source_cluster_addr,
                "token": source_cluster_token
            },
            "pchannels": source_cluster_pchannels
        },
        {
            "cluster_id": target_cluster_id,
            "connection_param": {
                "uri": target_cluster_addr,
                "token": target_cluster_token
            },
            "pchannels": target_cluster_pchannels
        }
    ],
    "cross_cluster_topology": [
        {
            "source_cluster_id": source_cluster_id,
            "target_cluster_id": target_cluster_id
        }
    ]
}

Примените к обоим кластерам:

from pymilvus import MilvusClient
source_client = MilvusClient(uri=source_cluster_addr, token=source_cluster_token)
source_client.update_replicate_configuration(**config)
source_client.close()
target_client = MilvusClient(uri=target_cluster_addr, token=target_cluster_token)
target_client.update_replicate_configuration(**config)
target_client.close()

После этого инкрементные изменения на основном кластере начнут автоматически реплицироваться на резервный.

Шаг 5: Убедитесь, что репликация работает

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

В Milvus Quickstart рассказывается о создании, вставке и поиске коллекций, если вам нужна справочная информация.

Запуск CDC в производстве

Настройка CDC - это самая простая часть. Для поддержания его надежности в течение длительного времени требуется внимание к нескольким операционным областям.

Отслеживайте отставание репликации

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

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

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

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

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

Таким образом, инфраструктура DR превращается в актив производительности. Резервная система зарабатывает даже тогда, когда ничего не сломано.

Правильно определяйте размер резервного хранилища

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

Тестируйте отказоустойчивость до того, как она понадобится

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

Остановите запись на основной сервер.
Подождите, пока резервный накопитель догонит основной (отставание → 0)
Перевести резервный сервер в другую категорию
Убедитесь, что запросы возвращают ожидаемые результаты
Обратный процесс

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

Не хотите сами управлять CDC? Zilliz Cloud справится с этим

Настройка и эксплуатация CDC-репликации Milvus - это мощный инструмент, но он сопряжен с операционными расходами: вы управляете двумя кластерами, следите за состоянием репликации, обрабатываете учебники обхода отказа и поддерживаете инфраструктуру в разных регионах. Для команд, которым нужна HA производственного уровня без операционной нагрузки, Zilliz Cloud (управляемая Milvus) предоставляет такую возможность из коробки.

Глобальный кластер - главная особенность Zilliz Cloud. Он позволяет запускать развертывание Milvus, охватывающее несколько регионов - Северную Америку, Европу, Азиатско-Тихоокеанский регион и другие - в виде единого логического кластера. Под капотом используется та же технология репликации CDC/WAL, о которой говорилось в этой статье, но с полным управлением:

Возможности	Самоуправляемый CDC (эта статья)	Глобальный кластер Zilliz Cloud
Репликация	Вы настраиваете и контролируете	Автоматизированный, асинхронный конвейер CDC
Отказоустойчивость	Руководство по выполнению вручную	Автоматизированный - без изменений кода, без обновления строк соединений
Самовосстановление	Вы сами перепрофилируете отказавший кластер.	Автоматически: обнаруживает устаревшее состояние, перезагружается и перестраивается как свежая вторичная система.
Межрегиональный	Вы развертываете и управляете обоими кластерами	Встроенная многорегиональность с локальным доступом для чтения
RPO	Секунды (зависит от мониторинга)	Секунды (незапланированное) / Ноль (запланированное переключение)
RTO	Минуты (зависит от вашего runbook)	Минуты (автоматически)

Помимо Global Cluster, план Business Critical включает дополнительные функции DR:

Point-in-Time Recovery (PITR) - откат коллекции к любому моменту в пределах окна сохранения, что полезно для восстановления после случайного удаления или повреждения данных, которые реплицируются на резервную копию.
Межрегиональное резервное копирование - автоматическая непрерывная репликация резервных копий в регион назначения. Восстановление на новых кластерах занимает считанные минуты.
Гарантия безотказной работы 99,99 % - поддерживается развертыванием нескольких кластеров с множеством реплик.

Если вы используете векторный поиск в производстве и DR является обязательным требованием, стоит оценить Zilliz Cloud наряду с самоуправляемым подходом Milvus. Свяжитесь с командой Zilliz для получения подробной информации.

Что дальше

В этой статье мы рассмотрели ландшафт HA для векторных баз данных и рассказали о создании пары "основной- резервный" с нуля. Далее:

Часть 2: Добавление CDC в существующий кластер Milvus, в котором уже есть данные, использование Milvus Backup для создания резервной копии перед включением репликации.
Часть 3: Управление обходом отказа - продвижение резервного сервера, перенаправление трафика и восстановление исходного основного сервера.

Оставайтесь с нами.

Если вы используете Milvus в производстве и думаете о восстановлении после сбоев, мы будем рады вам помочь:

Присоединяйтесь к сообществу Milvus Slack, чтобы задавать вопросы, делиться своей архитектурой HA и учиться у других команд, работающих с Milvus в масштабе.
Запишитесь на бесплатную 20-минутную сессию Milvus Office Hours, чтобы узнать о настройках DR - будь то конфигурация CDC, планирование обхода отказа или развертывание в нескольких регионах.
Если вы предпочитаете пропустить настройку инфраструктуры и сразу перейти к готовой к производству HA, Zilliz Cloud (управляемая Milvus) предлагает межрегиональную высокую доступность благодаря функции Global Cluster - ручная настройка CDC не требуется.

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

В: Замедляет ли CDC работу основного кластера?

Нет. Узел CDC читает журналы WAL асинхронно, независимо от пути чтения/записи. Он не конкурирует с запросами или вставками за ресурсы на основном кластере. Вы не увидите разницы в производительности при включенном CDC.

Вопрос: Может ли CDC реплицировать данные, существовавшие до его включения?

Нет - CDC фиксирует изменения только с момента включения. Чтобы перенести существующие данные в резервную копию, используйте Milvus Backup для посева резервной копии, а затем включите CDC для текущей репликации. Во второй части этой серии рассказывается об этом рабочем процессе.

Вопрос: Нужен ли мне CDC, если у меня уже включена мультирепликация?

Они защищают от разных режимов сбоя. Мультирепликация хранит копии одних и тех же сегментов на узлах одного кластера - отлично подходит при сбоях узлов, но бесполезна, когда весь кластер не работает (неудачное развертывание, отключение AZ, удаление пространства имен). CDC хранит отдельный кластер в другой области отказов с данными практически в режиме реального времени. Для любых задач, выходящих за рамки среды разработки, вам нужны оба варианта.

В: Как Milvus CDC сопоставляется с репликацией в других векторных базах данных?

Большинство векторных баз данных сегодня предлагают избыточность на уровне узлов (эквивалент мультирепликации), но не имеют репликации на уровне кластера. В настоящее время Milvus - единственная крупная векторная база данных со встроенной репликацией CDC на основе WAL - та же проверенная схема, которая используется в реляционных базах данных, таких как PostgreSQL и MySQL, уже несколько десятилетий. Если требуется кросс-кластерная или кросс-региональная отказоустойчивость, это важный фактор, который следует оценить.