在使用Solr（我们当前使用3.5）时，如何设置故障转移的主设备？高可用性的Solr主从故障转移设置
让我说在我的安装程序中我有两个大师和两个奴隶。应用程序将所有写入提交给一个主动主站，并且两个从站都从该主动主站获取更新。还有另一个中继器可以达到主人的相同目的。
现在我的问题是，如果师父出于某种原因倒下了，我怎样才能让Repeater成为Master而不需要任何人工干预。奴隶如何开始从中继器获取更新，而不是断开的主控器。有没有推荐的方法来做到这一点？是否还有其他建议的主/从设置来确保Solr系统的高可用性？
目前，您最好的选择可能是调查当前Solr 4.0 alpha中的SolrCloud功能，该功能在撰写本文时将在几个月内发布。 SolrCloud的目标是处理数据分配和主选举，使用ZooKeeper分布式数据库在集群内保持关于哪些节点在角色中服务的共识。
还有其他更传统的方法来为Solr 3的复制主从架构设置故障切换，但我个人不希望在Solr 4.0这么接近发布的情况下进行投资。
编辑：参见Linux-HA，用于一种这样的传统方法。就我个人而言，我将创建一个专门构建的守护进程，用于重新配置核心和负载平衡器，使用ZooKeeper进行状态检测和分布式锁定。
如果外包是一种选择，您可以考虑托管服务，如我自己的谦虚Websolr。我们默认提供这种分发和热故障转移，因此我们的客户不必担心如何实施它的机制。
我同意尼克。复制在Solr 3.x中的工作方式并不总是很方便，尤其是对于主节点故障切换。如果你打算考虑Solr 4，你可能也想看看elasticsearch，它以非常出色的方式解决了这类问题！
它使用推复制而不是Solr使用的拉机制。这意味着文档在所有节点上都被重新编制索引。这可能听起来很奇怪，但可以减少网络负载（例如由于段合并）。此外，一个节点被选为主节点，如果它崩溃，另一个节点将自动替换它成为新的主节点。
感谢Javanna的回应！ – Ravi 2012-08-10 14:43:39
ElasticSearch是一款精心设计的+1，专门用于从头开始分发，无需遗留代码即可保留。在这两种情况下（ES，SolrCloud），多主推送复制都是一个巨大的胜利。 – 2012-08-13 15:57:39
感谢您的答复尼克。虽然我想探索Solr Cloud的选项是一种可能性，但我想知道是否有办法用Solr 3来实现这一点，因为我们已经在此基础上构建了我们的框架。 – Ravi 2012-08-10 14:41:51
我的观点的一部分是，你设定的Solr 3中自动大师选举的任何解决方案都将比完成Solr 4更多的工作。另外，它可能会积极推迟你将来转向Solr 4作为沉没成本。 – 2012-08-13 16:01:34
编辑与Solr <4. – 2012-08-13 16:13:24