Solr 3x "中继器"和多个数据中心:
Solr 3x让一个节点同时作为和从节点和主节点，从一个主节点获取数据，然后将副本向下游提供给自己的从节点。这是如此普遍/有用，甚至有一个名字，"中继器"。
如果您想要跨多个数据中心，这非常有用。您可以在数据中心A (DCA)中拥有真正的主机，在数据中心B (DCB)中拥有"中继器"。然后中继器将从DCA获取内容并馈送DCB中的所有其他节点，节省带宽。
假设您希望将此设置升级到Solr 4x和SolrCloud。(注意Solr 4x仍然支持Solr 3x风格的传统复制)
据说您应该而不是拥有一个跨不同数据中心的SolrCloud集群。所以数据中心B应该有它自己的SolrCloud。
一个想法是让DCA -> DCB链接仍然使用Solr 3x风格的主/从复制。然后DCB中的"中继器"，也是一个SolrCloud节点，将自动传播到其他节点。
主要问题:一个Solr节点既可以参与Solr 3x风格的主/从模式(作为slave)，也可以成为SolrCloud集群的一部分吗?如果是，它是如何配置的?
并发症:
在简单的情况下，如果只有一个带有副本的分片，那么很容易看出它在数据方面是如何工作的。如果在DCB中有多个分片，则不太清楚，我如何告诉每个分片只复制自己的数据共享?请注意，SolrCloud通常通过事务进行复制，而3x使用二进制索引。
另一个复杂性是如果你在做复制。如何告诉每个分片只从远程DCA节点拉出一个主节点?
的替代品:
一个解决方案是升级到4x，但在DCB中继续使用3x风格的复制，所以不要使用SolrCloud。
我意识到另一个解决方案是让数据源将其更新发送到两个数据中心，或者使用像RabbitMQ这样的东西。为了这个问题，让我们假设这不是一个选项(说来话长…)
也许还有其他我没有想到的方法?
有没有人尝试过让SolrCloud跨数据中心?有多可怕?
一定有人问过这个问题!
但是我在谷歌上搜索了一下，虽然它找到了大量带有关键字的页面，但我还没有看到这种特定的"混合"模式。我从2013年找到了一个线程，但它并没有真正谈论配置和复杂性。
回答你的第一个问题，3中的一个Solr slave。X样式不能是Solr Cloud中的节点。原因是主/从3中的从。X Solr配置只是逐字节地复制主服务器上的所有索引文件。这就是它的全部功能。在中继器配置中，它也可以是供其他人复制的主站，或者是专用的查询从站，或者两者兼而有之。但就是这样。
Solr Cloud配置中的节点是分布式计算集群的完全参与者，在分布式计算集群中，索引通常分布在所有节点上，并且所有节点都参与查询。这是一个非常强大的功能，可以自动处理故障节点，并大大减轻了扩展的工作量，这在3中是非常手动的。X风格。
然而，你为此付出的部分代价是增加了复杂性(Zookeeper)，需要更低延迟的节点间通信(因为所有节点现在都相互通信并与Zookeeper通信)，以及失去了主/从复制的简单性。
在20M文档时，您完全处于单节点主索引的约束之下，并且具有有效的无限数量的从索引，因此具有非常高的查询容量。我今天在一个生产环境中这样做，其中每个主文档大约有60M个文档，没有明显的问题。
问题是你是否需要NRT、多节点索引、自动故障转移、自动扩展超过100M文档的能力?如果是这样，那么Master/Slave可能不会为你工作。
您可以看看如何将相同的数据写入两个不同的Solr Cloud集群，每个数据中心一个。你可以直接这样做，或者使用Apache Flume这样的工具来帮你做——这样做会有一些问题，所以真正的问题是，为了获得Solr Cloud的额外好处，处理这些问题是否值得?