Confluent Schema Registry Master - PullRequest
       18

Confluent Schema Registry Master

0 голосов
/ 10 июля 2019

Для межсетевой платформы слияния у нас есть один локальный кластер kafka, а другой - на AWS, в котором данные реплицируются с локального на AWS с использованием зеркала. Оба кластера независимы со своим собственным реестром схемы, оставшимся прокси и соединением. Оба кластера имеют различный набор производителей и потребителей, и отдельные кластеры отражаются между кластерами.

Какой должна быть лучшая практика для развертывания схемы-реестра? Должны ли мы иметь одного мастера (скажем, на месте) и других рабов на месте и AWS?

Мы подозреваем, что схема-реестр может иметь проблемы с идентификаторами схем, когда темы реплицируются между кластерами, и у нас есть 2 мастера (aws и onprem).

Спасибо!

1 Ответ

1 голос
/ 16 июля 2019

Если вы используете два разных основных реестра, я считаю, что это будет трудно управлять. ( См. Ошибку № 2 для реестров с самостоятельным управлением ). Цель master.eligble=false для второго экземпляра / кластера состоит в том, чтобы все события регистрации идентификаторов имели единый источник правды. Как говорится в документации, Узлы реестра схемы в обоих центрах обработки данных связаны с основным кластером Kafka в DC A , поэтому в любом случае вам потребуется установить действительную сетевую связь между AWS и onprem ,

В противном случае при наличии нескольких мастеров вам потребуется зеркально отразить тему схем, если вы хотите, чтобы между средами были одни и те же объекты и идентификаторы схем. Тем не менее, это в первую очередь предназначено для использования в качестве резервной копии, и вы в конечном итоге столкнетесь с конфликтующими идентификаторами схемы для любого производителя в регионе назначения, передающего схемы другому мастеру. Поэтому первая диаграмма показывает только потребителей в удаленном центре обработки данных.
Если вы этого не сделаете, то, скажем, вы отразили тему от кластера A до кластера B, а потребитель использовал реестр B в настройках, он попытался бы найти идентификатор из реестра A (который встроен в сообщение), и что либо не существует, либо будет неправильным идентификатором для читаемой темы.

Я написал плагин Kafka Connect, чтобы обойти эту проблему, зарегистрировав новый идентификатор в удаленном главном реестре - https://github.com/cricket007/schema-registry-transfer-smt, хотя вы сказали, что используете MirrorMaker, поэтому вам нужно будет принять логику там и примените его к интерфейсу MessageHandler в MirrorMaker

Я действительно работал только с одним ведущим, и в AWS настройки реестра имеют соединение Zookeeper, указывающее на предварительные настройки кластера.

И мы не отражаем все, как предлагают документы, только конкретные темы. Цель использования Replicator, а не MirrorMaker, заключается в том, что отказоустойчивость потребителя лучше поддерживается, чем просто получение данных «по проводам», ваши клиенты меньше зависят от того, где они работают.

...