我们计划在我们的解决方案中实现 SolrCloud （主要是出于数据复制和灾难恢复的目的），不幸的是，我们的某些客户只有2个DC，并且一个DC可能会被完全摧毁。
我们知道在2个位置运行ZK是有问题的，因为ZK需要仲裁。并且具有2个ZK节点的任何一侧的停机都将导致群集故障。位置之间的网络分区也会触发群集故障（由于仲裁失败，主机将不再是主机，而出于相同的原因，从机也无法选举自己）。
-
因此，我们当前的计划A 将对两个站点使用单个ZK，并将ZK备份到另一个站点。因此，如果没有ZK的站点死亡，我们可以。如果带有ZK的站点死亡，我们应该能够从备份启动新的ZK并重新配置Solr。
-
我们还考虑了计划B 在站点之间进行经典的主从复制。但是我们使用的是时间路由别名，因此我们需要SolrCloud功能，因此我们还需要在ZooKeeper中复制数据/配置（不仅是Solr索引）。因此，这种情况似乎只是Solr中的更多手动工作，而我们仍然需要备份/还原ZK。因此该计划被拒绝。
-
计划C 的价格可能是2ZK，但是重量较大的一种。这样可以减轻重量并减轻ZK的损坏和死亡。应该使用标准群集机制自动备份第一个ZK节点。但是我什至不知道有人用这种方式使用ZK ...
-
有没有更聪明的方法，如何在2节点环境中设置SolrCloud？我们应该选择哪种解决方案？
我们不期望高可用性；我们要实现灾难恢复。在节点发生故障的情况下，可以预期会有管理员的干预，我们只需要对短时间的网络故障有弹性。
编辑：带有时间路由别名的CDCR（跨数据中心复制）
我们正在考虑使用TRA，因为我们的数据是基于时间的，并且客户通常只对最新的片/分区感兴趣。如果没有TRA，索引就会增长，性能会下降，索引和RAM中的东西更多（未使用/旧）...
根据文档source&target collection parameters are required，CDCR出现了问题。但是，使用TRA时，会自动（每X天/月）使用相同的solrconfig.xml创建集合。 CDCR中的此问题为known（请参阅注释），但为not resolved yet。
另外，似乎CDCR确实不同步ZooKeeper（我在文档，jira和代码中都未提及该功能），这对于静态数量的集合可能是可以的，但是对于动态创建的集合却非常成问题（尤其是通过某些在用户/开发人员外部代码背后的机制）。
编辑：根据David（TRA的主要作者），CDCR&TRA combination is not to be supported。