Milvus CDC

Milvus CDC (Change Data Capture) реплицирует изменения данных с одного кластера Milvus на другой. Вы можете использовать CDC для построения топологии аварийного восстановления Milvus по принципу "основной - резервный".

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

Архитектура

Типичная топология содержит:

• Первичный кластер: Кластер-источник для репликации. Он принимает данные на чтение и запись.
• Резервный кластер: Целевой кластер для репликации. Он получает изменения от основного и доступен только для чтения, пока остается резервным.
• Узел CDC: Компонент Milvus, который пересылает изменения WAL с текущего основного на резервные кластеры. Разверните CDC на каждом кластере, который может стать основным после переключения или обхода отказа.
• Топология репликации: Настроенная связь между источником и целью, например кластер-a -> кластер-b. Ниже приведена иллюстрация топологии. Рабочий процесс CDC .

Поддерживаемые топологии

Наиболее распространенное развертывание CDC - это один основной и один резервный:

Application writes
      |
      v
Primary cluster A  -- CDC replication -->  Standby cluster B

Milvus CDC также поддерживает топологию с одним основным и несколькими резервными:

Primary cluster A  -- CDC replication -->  Standby cluster B
                  \-- CDC replication -->  Standby cluster C

Milvus CDC не поддерживает многоопорные или активно-активные развертывания, когда два или более кластеров принимают трафик записи одновременно.

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

Роль	Чтения	Записи	Поведение при репликации
Основной	Да	Да	Отправляет изменения в резервные кластеры
Резервный	Да	Нет	Получает реплицированные изменения от основного.

Резервный кластер отклоняет прямые запросы на запись. Это предотвращает "раздвоение мозга" и сохраняет согласованность топологии репликации.

Запланированное переключение по сравнению с обходом отказа

Milvus CDC предоставляет два способа перемещения служебного трафика с текущего основного кластера на резервный.

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

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

Задержка CDC и почему она важна

Задержка CDC - это количество данных, которые были записаны в основной кластер, но еще не были применены к резервному кластеру.

Задержка CDC влияет на оба варианта восстановления:

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

Необходимо постоянно следить за задержкой CDC и поддерживать ее на минимальном уровне. На странице Настройка CDC-репликации приведен пример PromQL для оценки задержки CDC.

Ограничения

В настоящее время Milvus CDC имеет следующие ограничения:

• Он поддерживает только топологии single-primary.
• Он не поддерживает активно-активные или мультипервичные записи.
• Резервные кластеры могут обслуживать трафик чтения, но отказываются от прямой записи, пока остаются резервными.
• При обходе отказа могут быть потеряны данные, которые были записаны на старый основной кластер, но еще не реплицированы на резервный.
• Настроенный pchannels должен соответствовать реальному расположению каналов в каждом кластере.

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

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

Да. Резервный кластер может обслуживать трафик чтения. Он не может принимать записи, пока не станет основным.

Поддерживает ли Milvus CDC активно-активную запись?

Нет. Milvus CDC разработан для топологии с одним основным кластером. Одновременная запись в несколько кластеров может привести к раздвоению мозга и расхождению данных.

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

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

Теряет ли данные обход отказа?

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

Сколько данных может быть потеряно при обходе отказа?

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