Solr 6.x升级至8.x的操作步骤、升级路径及索引迁移方案咨询

核心问题实操答复 #

索引处理要求 #

• 不需要执行全量数据导出-清空-重导的重型迁移操作。Solr底层依赖的Lucene索引具备旧格式读取能力，跨版本启动后可正常读取存量索引的数据，但旧格式的索引段文件在8.x版本中无法发挥最优性能，还会触发长期兼容性告警，甚至引发分片崩溃。
• 仅需对存量索引做原地格式适配升级即可：8.x版本集群稳定后，对每个core执行段重写操作，把旧版本生成的索引段转换为8.x原生支持的格式，整个过程直接改写磁盘上的现有索引文件，不需要搬运全量文档，耗时远低于全量数据迁移。
• 注意：跳过格式适配的临时可读状态不具备生产可靠性，不要抱着侥幸心理直接接业务流量。

版本升级路径要求 #

• 从落地经验看，不支持从6.x直接跨版本裸升到8.x。Solr官方仅对相邻大版本的升级路径做全场景兼容性验证，跨两个及以上大版本的直接升级没有任何保障，大概率会遇到配置解析失败、自定义插件类加载报错、shard路由逻辑异常、ZooKeeper元数据版本不匹配的问题。
• 必须遵循分阶段升级路径：先将6.x版本升级到6.x系列最后一个维护版（6.6.6），再升级到7.x系列最终稳定版（7.7.3），最后再升级到8.x目标稳定版（优先选择8.11.x等经过长期生产验证的版本，不选刚发布的早期小版本）。每个阶段升级完成后至少观察1个工作日的核心指标，确认写入、查询、副本同步功能正常，再推进下一阶段升级，绝对不要为了压缩升级周期跳级。

标准化升级操作流程 #

• 升级前前置准备
  • 完成全量离线备份：备份范围包含每个节点的Solr程序目录、core配置+索引存储目录、ZooKeeper中存储的Solr集群元数据，备份文件存储在和当前集群完全离线的独立介质上，备份完成后要做一次恢复演练，避免出现“备份完成但无法恢复”的无效备份。
  • 完成兼容性预排查：梳理所有自定义插件、分词器、请求处理器、solrconfig.xml自定义参数，对照每个目标版本的变更说明逐一核对冲突点（比如8.x默认调整了隐式路由逻辑、部分旧分析器类路径做了迁移），提前在测试环境把配置调整到可正常运行的状态。
  • 清理集群历史遗留问题：合并长期未处理的超大索引段、修复长期离线的副本节点、对齐ZooKeeper和本地节点的元数据，避免这些小问题在跨版本升级时触发连锁故障。
• 分阶段滚动升级
  • 第一阶段：将集群从当前6.x版本滚动升级到6.6.6版本，逐台节点重启，每台节点升级完成后确认集群状态恢复绿色，再操作下一台。
  • 第二阶段：将集群从6.6.6版本滚动升级到7.7.3版本，升级期间临时关闭自动分片重平衡、副本自动迁移逻辑，减少集群额外资源开销，降低升级过程中的故障概率。
  • 第三阶段：将集群从7.7.3版本滚动升级到目标8.x版本，所有节点完成升级后，等待集群状态稳定、副本同步完成，再启动索引适配流程。
• 索引格式适配操作
  • 对每个core运行Solr安装包自带的工具org.apache.lucene.index.IndexUpgrader，传入对应core的索引存储路径，工具会原地完成旧段格式的重写升级。
  • 适配完成后做核心一致性校验：对比升级前后的core文档总数、核心业务查询的返回结果集规模、写入QPS、查询延迟指标，确认无数据丢失、性能异常问题后，逐步放开全部业务流量。
• 回滚兜底方案
  • 一旦升级过程中出现core无法加载、索引损坏、集群状态长期无法恢复的问题，直接使用之前留存的离线快照回滚对应节点的程序目录、索引文件，使用备份的ZooKeeper元数据重启集群，不要在故障状态下硬尝试修复，避免故障范围扩大。

内容的提问来源于stack exchange，提问作者Arockia Ruban