OpenStack Keystone从Juno(2014.2.4)跨版本升级至Caracal(2024.1)的数据库迁移咨询

推荐的分步升级路径 #

OpenStack官方不支持跨10个版本的直接升级，但有明确的基于LTS版本的逐次升级路径，能最大程度降低风险：

• Juno → Liberty（2015.2） → Mitaka（2016.2） → Queens（2018.2） → Train（2020.2） → Yoga（2022.2） → Caracal（2024.1）
• 优先选LTS版本的原因是这类版本的迁移脚本经过充分验证，社区文档更完善，能避开非LTS版本的小众兼容性问题

简化中间版本升级的实操技巧 #

针对你提到的Docker镜像和Python兼容性问题，可通过以下方式降低复杂度：

• 直接使用官方容器镜像：每个版本的Keystone官方镜像已内置对应Python环境和依赖，无需自定义构建。拉取openstack/keystone:liberty、openstack/keystone:queens等标签的镜像，启动临时容器即可执行数据库迁移命令
• 离线迁移数据库：将Juno的数据库导出为SQL文件，在每个中间版本的容器中导入该SQL，执行keystone-manage db_sync完成schema升级后，再导出SQL进入下一个版本。此方式无需搭建完整Keystone服务，仅需容器提供迁移环境
• 跳过非必要配置：中间版本升级仅需关注数据库schema变更，无需配置API服务、认证组件等，减少额外工作量

数据库迁移关键注意事项 #

• 全量备份前置：每个版本迁移前必须备份当前数据库，迁移完成后再次备份，确保出现问题可快速回滚
• 分阶段执行迁移：从Newton版本开始，keystone-manage db_sync支持--expand和--contract分阶段执行，避免一次性迁移导致的锁表或数据丢失
• 验证自定义数据兼容性：若Keystone存在自定义属性、角色或项目数据，需提前确认每个中间版本是否支持对应字段，必要时临时修改SQL适配

社区常见应对方案 #

• 使用社区迁移脚本：部分开发者分享了跨版本迁移辅助脚本，可批量处理密码哈希升级、废弃字段清理等操作，但需先验证脚本安全性再使用
• 全新搭建+数据导入：若分步升级过于繁琐，可直接搭建Caracal版本Keystone，通过Keystone API导出旧版本的用户、角色、项目数据，再导入新环境。此方式适合数据量较小的场景，避开复杂的schema迁移
• 专业服务支持：生产环境可寻求OpenStack商业支持厂商的专业服务，厂商会提供定制化的跨版本升级方案，降低业务中断风险

内容的提问来源于stack exchange，提问作者Alec Chepkin