TL;DR: Раньше миграция с 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 обычно тормозит весь проект. Это последний компонент, который кто-либо оценивает. Он находится между каждым продюсером и каждым консьюмером, а команды приложений постоянно развивают общие контракты данных. Ошибка здесь может сломать все приложения сразу, а не только те, которые используют конкретный топик.
Раньше это делалось вручную следующим образом: выгрузить каждый субъект из Confluent Schema Registry с помощью скрипта. Загрузить их в новый реестр, соблюдая порядок зависимостей. Ошиблись в ссылке — импорт не удался. Перенастроить параметры совместимости для каждого субъекта, потому что они не переносятся автоматически. Затем выровнять ID, так как формат передачи данных зашивает ID схемы в каждую запись, и ваши консьюмеры с радостью будут десериализовать мусор, если эти ID не совпадают. Затем повторить все сначала, пока вы писали скрипт, схемы продолжали меняться.
Redpanda Migrator в составе Redpanda Connect частично упростил эту задачу, но это все равно был еще один развертываемый компонент, который нужно настраивать, защищать и обслуживать на протяжении всей миграции. Для многих команд, управляющих критически важной инфраструктурой потоковой передачи, период параллельной миграции без простоя (с полным циклом тестирования приложений посередине) создавал избыточную сложность, из-за чего проект бесконечно откладывался на «следующий квартал».
Shadowing уже умел реплицировать схемы. Теперь он синхронизирует их из любого кластера Confluent.
Репликация схем в режиме «байт-в-байт» между кластерами Redpanda уже работала в предыдущих версиях путем создания тени внутреннего топика _schemas. Нововведением версии 26.2 является репликация Schema Registry в режиме API. Вместо обязательного использования источника Redpanda, теневой кластер опрашивает любой реестр, поддерживающий стандартный REST API Schema Registry (включая Confluent и Kafka). Затем Shadowing импортирует все субъекты, версии и настройки совместимости непосредственно во встроенный Schema Registry от Redpanda.
Под капотом Shadowing работает на основе запросов на вытягивание (pull). Каждый брокер в теневом кластере выполняет задачи репликации, которые получают данные из источника через стандартные API Kafka и Schema Registry. Теперь вся миграция выполняется по одной ссылке: данные топиков со стороны Kafka, схемы со стороны реестра, а также оффсеты потребителей и ACL рядом с ними. Один файл конфигурации, мастер в пользовательском интерфейсе, Kubernetes CRD или модуль Terraform для заполнения и автоматизации. Выбирайте то, что вам по душе.
Половина конфигурации, отвечающая за реестр схем, выглядит максимально просто:
Здесь два цикла синхронизации поддерживают актуальность реестров. Инкрементная синхронизация (tail sync) запускается по умолчанию каждые 10 секунд и улавливает точечные изменения. Полная синхронизация (full sync) сканирует все выбранные субъекты каждые пять минут, чтобы подхватить все, что было пропущено инкрементной синхронизацией. Предусмотрен настраиваемый лимит частоты запросов (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 можно выполнять отработку отказа (failover) по одному топику за раз. Таким образом, миграция превращается в последовательность небольших, незаметных для конечных пользователей переключений. Выберите приложение с наименьшим риском, переведите его топики, направьте его продюсеры и консьюмеры на 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 (shadow cluster) на свое развертывание Confluent или Kafka и оставьте его в таком состоянии. Топики, смещения, списки управления доступом (ACL) и схемы реплицируются непрерывно. Теперь у вас есть горячий резерв на другой платформе, в другом домене сбоев и с другой поддержкой, как правило, по гораздо более низкой цене, чем второй кластер Confluent. Это создает трамплин для будущей миграции на Redpanda и повышает надежность вашей критически важной инфраструктуры потоковой передачи данных.
Некоторые команды используют эту конфигурацию в течение квартала или дольше, прежде чем переключать что-либо. Это полноценное самостоятельное решение (Redpanda как кластер аварийного восстановления для основного кластера Confluent или Kafka) и наиболее честный способ оценки миграции, поскольку теневой кластер содержит ваши реальные производственные схемы и данные все это время. Во время миграции в Redpanda также можно запускать синтетические рабочие нагрузки, выступающие в роли некоего промежуточного кластера и еще больше повышающие уверенность.
Убедитесь в этом на практике от начала и до конца
Лучше один раз увидеть, поэтому мы создали практическую лабораторию, которая запускает настоящий стек 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.
Теневое копирование и репликация схем в режиме 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 ContextsRedpanda 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
- Закажите демонстрацию, чтобы узнать больше
