在使用 Solr（我们目前使用的是 3.5）时，我们如何设置 Masters 以进行故障转移？
假设在我的设置中我有两个主人和两个奴隶。应用程序将所有写入提交到一个活动的主服务器，两个从服务器都从这个活动的主服务器获取更新。还有另一个中继器与 Master 的目的相同。
现在我的问题是，如果 Master 出于某种原因倒下，我如何在没有任何手动干预的情况下将 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 使用的拉取机制。这意味着文档在所有节点上都被重新索引。听起来可能很奇怪，但这可以减少网络负载（例如由于段合并）。此外，一个节点被选为主节点，如果它崩溃，另一个节点将自动取代它成为新的主节点。