Кратко: Миграция с Confluent раньше означала использование MirrorMaker, пользовательских скриптов и рискованного переключения в выходные дни. С версии 26.2 это в прошлом. Redpanda Shadowing теперь запускает живую репликацию вашего кластера Confluent Cloud, Confluent Platform (или любого другого источника Apache Kafka®), передавая данные топиков, схемы, смещения и ACL по единой связи. Благодаря этому вы можете сначала протестировать реальные рабочие нагрузки, а затем переключать приложения по одному в удобном для вас графике. Уже доступно в Redpanda Self-Managed 26.2, а также в Redpanda Cloud BYOC и Dedicated.
Приобретение Confluent компанией IBM, завершившееся в марте 2026 года, заставило команды платформ пересмотреть свои стратегии потоковой передачи данных и поставщиков. Большинство наблюдателей ожидают, что IBM направит развитие своей экосистемы в сторону закрытой экосистемы в стиле «только от IBM», а не останется независимым специалистом по современному связующему ПО, каким был Confluent.
Когда мы общаемся с командами, переоценивающими свой стек технологий, они редко говорят: «Мы не уверены, что Redpanda лучше». Чаще мы слышим: «Мы знаем, что она лучше, но миграция выглядит рискованной, и мы не можем включить ее в дорожную карту». Это вполне разумный подход.
Исторически миграция с Confluent означала развертывание отдельного стека репликации с помощью MirrorMaker (на базе Kafka Connect), необходимость мириться с транслируемыми смещениями, самостоятельную миграцию Реестра схем (Schema Registry) и риск для всего бизнеса во время масштабного переключения в выходные. Слишком много движущихся частей и точек отказа, из-за чего проект буксует, а модернизация откладывается еще на квартал.
Функция Redpanda Shadowing в версии 26.2 устраняет этот риск. Shadowing — это встроенная в брокер функция репликации с сохранением смещений и полной точностью данных, которую клиенты Redpanda уже используют для аварийного восстановления (DR), миграции оборудования и распространения данных между регионами облака и дата-центрами. Начиная с версии 26.2, в качестве исходного кластера также может выступать Confluent Cloud, Confluent Platform или любой другой кластер, совместимый с Kafka и использующий открытый Schema Registry. Результатом становится контролируемая миграция в параллельном режиме, которая гарантирует бесперебойную работу всех старых приложений Confluent.
Почему именно Schema Registry становился камнем преткновения
В планах миграции все внимание обычно приковано к топикам, и это справедливо. Именно там хранятся данные. Но именно Schema Registry чаще всего тормозит проект. Это последний компонент, объем работ по которому оценивается; он находится между каждым продюсером и консьюмером, в то время как команды постоянно развивают общие контракты данных. Ошибка здесь может вывести из строя сразу все приложения, а не только те, которые используют конкретный топик.
Раньше это делалось вручную следующим образом: с помощью скрипта выгружался каждый субъект из Schema Registry компании Confluent. Затем они импортировались в новый реестр с соблюдением порядка зависимостей. Стоило ошибаться в одной ссылке — и импорт завершался ошибкой. Приходилось заново настраивать параметры совместимости для каждого субъекта, поскольку они не переносились автоматически. Затем требовалось согласовывать ID, так как формат передачи данных встраивает ID схемы в каждую запись, и ваши консьюмеры с радостью начнут десериализовать мусор, если эти ID не совпадают. И наконец, всю процедуру приходилось повторять сначала, потому что схемы продолжали меняться, пока вы писали скрипт.
Инструмент Redpanda Migrator в составе Redpanda Connect частично упростил эту задачу, но это все равно была еще одна развертываемая система, которую нужно было настраивать, защищать и сопровождать на протяжении всей миграции. Для многих команд, управляющих критически важной инфраструктурой потоковой передачи данных, период параллельной миграции без простоев (с полным циклом тестирования приложений посередине) создавал избыточную нагрузку, из-за чего проект бессрочно переносился на «следующий квартал».
Функция Shadowing уже умела реплицировать схемы. Теперь она синхронизирует их из любого кластера Confluent.
В более ранних выпусках репликация схем между кластерами Redpanda уже работала побайтово через дублирование внутреннего топика _schemas. Главное нововведение версии 26.2 — репликация Schema Registry в режиме API. Вместо обязательного использования источника Redpanda, теневой кластер (shadow cluster) опрашивает любой реестр, поддерживающий стандартный REST API Schema Registry (включая Confluent и Kafka). Затем Shadowing импортирует все субъекты, версии и настройки совместимости непосредственно во встроенный Schema Registry компании Redpanda.
Под капотом Shadowing работает на основе запросов на вытягивание (pull-based). Каждый брокер в теневом кластере выполняет задачи репликации, которые извлекают данные из источника через стандартные API Kafka и Schema Registry. Теперь вся миграция умещается в рамках одной связи: данные топиков со стороны Kafka, схемы со стороны реестра, а также смещения потребителей и списки ACL. Достаточно заполнить и автоматизировать один файл конфигурации, мастер в пользовательском интерфейсе, Kubernetes CRD или модуль Terraform. Выбирайте то, что вам ближе.
Конфигурация половины, отвечающей за реестр схем, выглядит максимально просто и предсказуемо:
Здесь два цикла синхронизации поддерживают актуальность реестров. Инкрементальная синхронизация (Tail syncs) запускается по умолчанию каждые 10 секунд и подхватывает изменения по мере их появления. Полная синхронизация (Full syncs) сканирует все выбранные субъекты каждые пять минут и находит всё, что было пропущено инкрементальной синхронизацией. Предусмотрен настраиваемый лимит частоты запросов (max_source_requests_per_second, по умолчанию 30), чтобы не перегружать исходный реестр. Это важнее, чем кажется, особенно когда источником является реестр Confluent Cloud, тарифицируемый по количеству запросов.
Несколько свойств, которые делают этот инструмент действительно мощным, а не просто работоспособным:
- Имена субъектов и ID версий сохраняются. Продюсеры и консьюмеры, определяющие схемы по ID, продолжают работать после переключения. Именно на этом этапе часто ломаются самодельные миграции.
- Ссылки на схемы импортируются с учетом порядка зависимостей. Субъекты, ссылающиеся на другие субъекты, разрешаются корректно. Поддерживается репликация сложных иерархических схем Avro, Protobuf и JSON Schema.
- Схемы проходят валидацию при импорте. Перед импортом Redpanda проверяет каждую схему на соответствие собственной реализации Schema Registry. Некоторые специфичные для Confluent расширения (наборы правил, теги метаданных, группы совместимости) не имеют прямых аналогов в Redpanda. Если такое расширение обнаруживается, значение FAIL (по умолчанию) пропускает эту схему и сообщает об ошибке, а REMOVE удаляет неподдерживаемые поля и импортирует остальное, не прерывая миграцию. В любом случае вы узнаете об этом в процессе наблюдения за синхронизацией, а не в момент необратимого переключения.
- Целевой кластер заблокирован для записи на время активности связи. Как и в случае с данными топиков, Redpanda отклоняет клиентские записи в те контексты схем, которыми управляет активная теневая связь, поэтому оба реестра не могут разойтись в процессе миграции. Контексты, находящиеся вне фильтра связи, остаются доступными для записи.
В Redpanda Cloud вы также можете управлять аварийным переключением непосредственно со страницы Shadow Link в консоли управления Cloud Console или через Data Plane API.
Что еще более важно, теневые связи (Shadow Links) можно переключать по одному топику за раз. Таким образом, миграция превращается в череду мелких, рутинных переключений, которые конечные пользователи даже не замечают. Выберите приложение с наименьшим риском, переключите его топики, направьте его продюсеры и консьюмеры на Redpanda, понаблюдайте за ним в течение недели и переходите к следующему.
Смещения групп потребителей уже реплицированы, поэтому консьюмеры возобновляют работу с того места, где остановились, вместо того чтобы сбрасывать их на начало партиций для полного повторного воспроизведения. Права ACL уже настроены, и вам не придется править политики авторизации в 2 часа ночи.
Управление масштабными многопользовательскими окружениями Confluent
Однокластерный демо-стенд — это простой случай. Реальные, зрелые развертывания Confluent / Kafka обычно похожи на результат десятилетней истории организации: один реестр на окружение, бизнес-подразделение, поглощение или ИТ-вотчину, с пересекающимися именами субъектов и политиками совместимости для каждого субъекта, которые никто не помнит, кто настраивал. Иногда эти кластеры используют общий реестр. Это означает, что вам понадобятся различные варианты.
Реестр схем Redpanda поддерживает контексты: независимые пространства имен для субъектов в рамках одного реестра, каждое из которых имеет собственный счетчик идентификаторов схем, режим и настройки совместимости. Эта реализация совместима с API контекстов Confluent, поэтому, если ваши инструменты уже используют контексты, они продолжит работать. Контексты включены по умолчанию в версии 26.2, а также на кластерах BYOC и Dedicated в Redpanda Cloud.
Это дает вам реальный контроль над тем, как именно пройдет миграция:
- Репликация подмножества. Параметр source_filter выбирает определенные контексты, конкретные субъекты или их объединение, используя квалифицированный синтаксис субъектов (:.staging:orders-value). Вам не нужно мигрировать все сразу, чтобы начать.
- Сохранение имен контекстов или их переназначение. Сопоставление identity сохраняет имена исходных контекстов, что является обычным выбором для прямой миграции. Точное сопоставление (exact) позволяет переименовывать контексты по ходу дела, что позволяет объединить несколько исходных реестров в один кластер Redpanda без конфликтов: каждый исходный реестр попадает в свой собственный целевой контекст.
- Изоляция команд без изоляции операций. Несколько команд используют один кластер Redpanda и Реестр схем с идентификаторами для каждого контекста и настройками совместимости, вместо того чтобы заставлять кого-то развертывать отдельный Реестр схем для каждой команды.
Еще не готовы к миграции? Используйте Redpanda в качестве страховочной сетки
Существует второе применение для этого же механизма, и именно с него начинают не склонные к риску команды.
Направьте теневой кластер Redpanda на ваше развертывание Confluent или Kafka и оставьте его в таком состоянии. Топики, смещения, списки контроля доступа (ACL) и схемы реплицируются непрерывно. Теперь у вас есть горячий резерв на другой платформе, в другом домене сбоев, с другими условиями поддержки и, как правило, по гораздо более низкой цене, чем второй кластер Confluent. Это создает трамплин для будущей миграции на Redpanda и повышает отказоустойчивость вашей критически важной инфраструктуры потоковой передачи данных.
Некоторые команды используют эту конфигурацию в течение квартала или дольше, прежде чем что-либо переключать. Это вполне самостоятельное целевое решение (Redpanda в качестве резервного кластера DR для основного кластера Confluent или Kafka) и самый честный способ оценить миграцию, поскольку теневой кластер все это время работает с вашими реальными производственными схемами и данными. Во время миграции в Redpanda также можно запускать синтетические рабочие нагрузки, выступающие в роли своего рода промежуточного кластера (staging) и еще больше укрепляющие уверенность.
Посмотрите на это в действии от начала и до конца
Лучше один раз увидеть, поэтому мы создали практическую лабораторию, которая запускает настоящий стек Confluent Platform (Confluent Kafka в режиме KRaft плюс Confluent Schema Registry) в качестве источника миграции и реплицирует все в теневой кластер Redpanda. Все это работает в Docker Compose и занимает всего 20 минут.
Лаборатория намеренно не ограничивается самым простым сценарием использования. Она регистрирует два простых субъекта Avro (orders-value, customers-value), устанавливает режим совместимости BACKWARD для одного из них и добавляет вторую, совместимую версию, а затем нагромождает те сложности, которые часто ломают миграции, сделанные своими руками:
- Ссылка на схему: shipping-value указывает на address-value, поэтому вы можете наблюдать, как функция Shadowing импортирует их в порядке зависимости.
- Субъект JSON Schema и субъект Protobuf наряду с субъектами Avro.
- Режим совместимости FULL_TRANSITIVE для одного из субъектов, чтобы подтвердить, что настройки для конкретного субъекта реплицируются корректно, а не возвращаются к глобальному значению по умолчанию.
Затем она генерирует реальные записи в кодировке Avro для кластера Confluent и считывает их обратно дважды: один раз сопоставляя схемы с реестром Confluent, а второй — с реестром теневого кластера Redpanda (переключение, требующее всего одного изменения конфигурации в приложении). Записи декодируются идентично в обоих случаях. Это и есть весь тест, который вы можете легко повторить в своем окружении Confluent со своими приложениями и схемами.
Лаборатория также проверяет, что реестр теневого кластера остается «заблокированным» до момента переключения на резерв, предотвращая повреждение реплики, и развертывает консоль Redpanda Console на теневом кластере, чтобы вы могли просматривать реплицированные схемы и данные или настраивать параметры связи и данные в пользовательском интерфейсе.
Если застрявшая миграция Реестра схем — это единственное, что стоит между вами и переключением, эта лаборатория покажет, что это больше не проблема. Ищите ее в Redpanda Labs.
Теневое копирование (Shadowing) и репликация схем в режиме API являются функциями уровня Enterprise и требуют либо лицензии Redpanda Enterprise, либо пробной версии Redpanda Cloud/BYOC. Вы можете сгенерировать пробный ключ, чтобы запустить лабораторию локально и оценить решение на собственном реестре.
Попробуйте сегодня
Многие платформенные команды уже некоторое время хотели модернизировать свою инфраструктуру Kafka и/или избавиться от влияния Confluent, но ждали, пока процесс миграции станет менее болезненным. Именно эту проблему мы решили в версии 26.2. И она уже доступна в Redpanda Self-Managed и Redpanda Cloud (кластеры BYOC и Dedicated).
Redpanda Shadowing теперь позволяет мигрировать с Confluent или Kafka так же, как она защищает вас от сбоев: плавно, с помощью актуальной реплики вашего кластера, сохраняющей смещения. Просто выполняйте синхронизацию и проверку ваших данных, схем, политик безопасности и полноценных приложений, а затем переключайтесь за один согласованный шаг. Никаких MirrorMaker, пользовательских скриптов, множества инструментов или масштабных миграций на выходных. Ваши приложения едва ли заметить переезд.
- Запустите лабораторию: labs/docker-compose/confluent-schema-registry-shadowing/
- Прочитайте документацию: Redpanda Self-Managed: Migrate Schemas from Confluent Schema Registry, Shadowing overview, Configure Shadowing, Schema Registry Contexts Redpanda Cloud: Migrate Schemas from Confluent Schema Registry, Shadowing overview, Configure Shadowing, Schema Registry Contexts
- Redpanda Self-Managed: Migrate Schemas from Confluent Schema Registry, Shadowing overview, Configure Shadowing, Schema Registry Contexts
- Redpanda Cloud: Migrate Schemas from Confluent Schema Registry, Shadowing overview, Configure Shadowing, Schema Registry Contexts
- Сравните платформы потоковой передачи: Redpanda и Confluent
- Закажите демо-версию, чтобы узнать больше