对于跨网络融合平台，我们在本地拥有一个kafka集群，在AWS上拥有另一个集群，其中的数据使用镜像制造商从本地复制到AWS。两个集群都独立于各自的架构注册表，REST代理和连接。两个集群都有不同的生产者和使用者集合，并且选择性主题正在集群之间进行镜像。
部署架构注册表的最佳实践应该是什么？我们是否应该在本地和AWS上拥有一个主机（例如本地）和其他从属？
当在集群之间复制主题并且我们有2个主服务器（aws和onprem）时，我们怀疑schema-registry可能在模式ID方面存在问题。
谢谢！
答案 0 :(得分：1)
如果您使用两个不同主注册中心，我会发现这很难管理。 （See mistake #2 for self-managed registries）。 master.eligble=false在第二个实例/群集上的目的是，所有ID注册事件都具有一个真实的来源。如文档所述，两个数据中心中的Schema Registry节点链接到DC A中的主要Kafka群集 ，因此您需要在AWS和onprem之间建立有效的网络链接，无论如何。
否则，如果要在多个环境之间使用完全相同的主题和模式ID，则对于多个母版，您将需要镜像模式主题。但是，这主要是用作备份，最终您将在目标区域中将模式推到另一个主服务器时遇到冲突的模式ID。因此，为什么第一个图仅显示远程数据中心中的使用者。
如果您不这样做，则假设您将一个主题从群集A镜像到群集B，并且使用者在设置中使用了注册表B，它将尝试从注册表A中查找ID（该ID嵌入在消息中），并且该名称将不存在，或者是所读取主题的错误ID。
我写了一个Kafka Connect插件来解决此问题，方法是在远程主注册表https://github.com/cricket007/schema-registry-transfer-smt中注册一个新ID，尽管您说过您正在使用MirrorMaker，所以您需要在其中使用逻辑并将其应用到MirrorMaker的MessageHandler界面
我实际上只使用一个主服务器，本地服务器，在AWS中，注册表设置具有指向本地本地群集设置的Zookeeper连接。
我们不会像文档所建议的那样镜像所有内容，而仅反映特定主题。使用Replicator而不是MirrorMaker的目的是更好地支持消费者故障转移，而不是简单地通过“有线”获取数据，您的客户端也不再依赖于它们的运行位置。