Apache Solr主-中继-从架构高可用故障转移方案咨询

问题1：仅通过Solr配置能否实现自动同步的多主架构？ #

结论明确：无法仅通过Solr原生配置实现这种多主架构。

Solr的原生复制机制基于ReplicationHandler，本质是单向的主从推送/拉取模式，没有内置多主节点间的自动冲突解决、双向同步能力。如果强行配置两个节点互相作为对方的主节点（所谓“主主”双向复制），会出现以下问题：

• 并发索引请求会导致数据冲突，Solr没有冲突检测与合并逻辑，无法自动修复数据不一致。
• 双向复制会引发循环同步，一旦节点间数据出现差异，会互相推送错误数据，最终导致索引彻底混乱。
• 没有自动故障切换的逻辑，节点故障时仍需人工介入调整配置，完全不符合高可用、少人工干预的要求。

所以必须采用专用主节点+备用主节点的架构，而非让所有节点同时作为可写主节点。

问题2：主节点故障转移的最佳实现方式 #

推荐架构：Active Master + Standby Master + Repeater + Slaves #

结合外部监控与自动化工具实现故障转移，Solr原生不提供自动故障转移能力，必须依赖外部组件（如Keepalived、自定义监控脚本、负载均衡器）配合。

正常状态下的复制逻辑 #

1. 主节点（Active Master）：
   • 处理所有索引请求，同时可处理搜索请求（因当前流量不大）。
   • 配置ReplicationHandler，允许中继节点拉取索引更新。
2. 中继节点（Repeater）：
   • 定期（通过pollInterval配置）向主节点请求索引更新，对比generation版本，拉取增量或全量索引。
   • 将更新推送给所有从节点，减轻主节点的复制压力。
3. 从节点（Slaves）：
   • 定期向中继节点拉取索引更新，仅处理搜索请求。
4. 备用主节点（Standby Master）：
   • 平时处于只读状态，通过ReplicationHandler同步主节点的索引数据，保持与主节点配置（schema、solrconfig）完全一致。

故障转移自动触发流程 #

1. 健康监控：用监控脚本或工具定期检测主节点状态——比如访问/admin/cores接口判断节点是否存活，检查索引写入请求是否能正常完成。
2. 切换执行：当检测到主节点故障时，自动执行以下步骤：
   • 修改备用主节点的配置：关闭其作为从节点的同步配置，开启UpdateHandler允许接受索引请求。
   • 更新中继节点的复制源：将中继节点的主地址改为备用主节点，中继节点开始从新主节点拉取更新并推送给从节点。
   • 调整路由：将前端索引请求的流量转发到新主节点，搜索请求可暂时切换到可用的从节点/中继节点（少量停机时间符合需求）。

原主节点恢复后的同步流程 #

1. 原主节点恢复后，先将其配置为备用主节点模式：修改solrconfig.xml，让它作为新主节点的从节点，拉取新主节点的全量索引（因为故障期间新主节点已处理了索引请求，数据存在差异）。
2. 等待原主节点完成全量同步后，保持其处于只读备用状态，作为下一次故障转移的候选节点。
3. 若需切换回原主节点：先暂停新主节点的索引写入，等待原主节点同步完所有剩余更新，再将流量切回原主节点，最后把新主节点切换回备用状态。

内容的提问来源于stack exchange，提问作者Nishant Mishra