1.3.0如何无损升级到2.4.0

[zhuangdl]

你好，1.3.0如何无损升级到2.4.0呢，目前数据较多，能直接数据库同步吗？
每个版本的 release note，仅提供上个版本升级到当前版本

[dosubot]

升级 Apollo 从 1.3.0 到 2.4.0 时，可以做到无损升级，但需要注意以下关键点：

1. 必须依次执行每个版本之间的数据库升级 SQL（delta 脚本），不能跳过中间版本。没有“一步到位”的升级脚本，必须按顺序从 1.3.0 → 1.4.0 → ... → 2.4.0 逐步升级数据库结构，确保数据和结构兼容性。参考
2. Apollo 的数据库 schema 设计为向后兼容，升级时无需停机。推荐先升级数据库，再逐个升级 Apollo 服务。参考
3. 数据量大时，直接同步数据库（如直接拷贝表数据）理论上可行，但强烈建议只做“读”操作，避免写入或结构变更导致线上环境数据不一致。务必在操作前做好完整备份。参考
4. 升级过程中涉及表结构变更（如 AccessKey 新增 Mode 字段、Commit/Namespace/Release 表默认值和索引调整等），务必用官方 SQL delta 脚本操作，避免遗漏。参考
5. 升级后建议重启 config service，避免缓存导致的数据不一致。参考

总结：升级时不要直接用新版本 SQL 覆盖旧库，必须按顺序执行所有升级脚本，做好备份，升级后重启服务。这样可以最大程度保证数据安全和无损升级。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[zhuangdl]

逐步升级数据库结构时，应用配置能否变更吗，如果SQL执行失败，是否会影响线上应用@dosu

[dosubot]

升级数据库结构时，Apollo 支持应用配置的正常变更和发布（通过界面或 Open API），不会因为数据库升级而被限制，升级过程本身也无需停机，线上应用可继续使用配置中心功能。参考

如果执行升级 SQL 时发生错误，是否影响线上应用主要取决于出错的具体环节和数据库的“continueOnError”参数。默认情况下（continueOnError=false），SQL 执行遇到错误会中断，未完成的结构变更可能导致新旧服务或配置操作异常，甚至影响线上应用的正常配置读取或发布。Apollo 本身不做额外的事务回滚或错误处理，依赖 Spring Boot 和数据库自身的机制。参考

建议升级前充分备份，升级过程中关注 SQL 执行结果，确保每步都成功，避免因结构不一致影响线上服务。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[zhuangdl]

我们是迁云的同时升级apollo，两种方案：
1、在A云逐步执行SQL升级数据库结构、apollo服务，然后再数据同步到B云
2、在B云搭建2.4.0 apollo，直接从A云数据同步到B云
更推荐哪个呢@dosu

[HadwinLing]

我们是迁云的同时升级apollo，两种方案： 1、在A云逐步执行SQL升级数据库结构、apollo服务，然后再数据同步到B云 2、在B云搭建2.4.0 apollo，直接从A云数据同步到B云 更推荐哪个呢@dosu

我们做迁云，但是没有升级，采用的是，在B云搭建一套新的1.4.0 的apollo，A云与B云间的数据，先全量同步到B云的库，增量数据利用flink cdc 同步过去B 云，推动其他业务逐步从A 云迁移到B云的Apollo，迁移期间，配置全在A云的Apollo 进行修改

[zhuangdl]

我们是迁云的同时升级apollo，两种方案： 1、在A云逐步执行SQL升级数据库结构、apollo服务，然后再数据同步到B云 2、在B云搭建2.4.0 apollo，直接从A云数据同步到B云 更推荐哪个呢@dosu

我们做迁云，但是没有升级，采用的是，在B云搭建一套新的1.4.0 的apollo，A云与B云间的数据，先全量同步到B云的库，增量数据利用flink cdc 同步过去B 云，推动其他业务逐步从A 云迁移到B云的Apollo，迁移期间，配置全在A云的Apollo 进行修改

谢谢，1.4.0版本有点低呀，后续还得升级

[zhuangdl]

我们是迁云的同时升级apollo，两种方案： 1、在A云逐步执行SQL升级数据库结构、apollo服务，然后再数据同步到B云 2、在B云搭建2.4.0 apollo，直接从A云数据同步到B云 更推荐哪个呢@dosu

帮忙看下呢 @nobodyiam @dosu

[dosubot]

两种方案各有优劣，结合 Apollo 的升级机制和云迁移常见实践，建议优先考虑方案1（在A云逐步升级数据库结构和服务，确认无误后再同步到B云）：

• 方案1的优势是：升级链路清晰，所有升级 SQL 都在原有环境顺序执行，能及时发现和修正升级过程中的问题，数据一致性和可控性更高。升级完成后再全量同步到B云，B云直接用升级后的数据和服务，风险较低。
• 方案2（B云直接搭建2.4.0，A云数据直接同步过去）的问题是：Apollo 升级必须严格按版本顺序执行所有 SQL delta 脚本，不能跳过中间版本。如果直接把1.3.0的数据同步到2.4.0的库，表结构和数据不兼容，容易出错，且后续补救复杂。

无论哪种方案，建议：

• 数据同步前后都要做完整备份。
• 升级过程中，Apollo 支持不停服变更配置，线上应用不受影响，但要关注 SQL 执行结果，避免结构不一致导致异常。参考
• 数据同步到B云后，建议重启 config service，避免缓存导致的数据不一致。参考

如果数据量极大、迁移窗口有限，也可以参考社区用 Flink CDC 做增量同步的做法，但升级链路还是建议在A云先升级到目标版本，确保数据和结构都符合2.4.0的要求后再迁移。这样风险最小、兼容性最好。

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[nobodyiam]

迁云和升级 apollo 建议同时只做其中一个变更，避免相互影响
@dosu 的回答很棒，进步非常大👍

[dosubot]

感谢认可！确实，迁云和 Apollo 升级建议分步进行，先完成一项再做另一项，能最大程度降低风险、便于问题定位。升级 Apollo 时，务必按版本顺序依次执行所有数据库升级脚本，升级完成后再做数据同步和服务切换，确保结构和数据一致性。整个过程中，Apollo 支持不停服变更配置，线上应用不受影响，但要密切关注 SQL 执行结果，做好备份，避免结构不一致导致异常。参考

有需要随时 @我！

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[zhuangdl]

感谢认可！确实，迁云和 Apollo 升级建议分步进行，先完成一项再做另一项，能最大程度降低风险、便于问题定位。升级 Apollo 时，务必按版本顺序依次执行所有数据库升级脚本，升级完成后再做数据同步和服务切换，确保结构和数据一致性。整个过程中，Apollo 支持不停服变更配置，线上应用不受影响，但要密切关注 SQL 执行结果，做好备份，避免结构不一致导致异常。参考

有需要随时 @我！

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other   

方案3：在B云搭建1.3.0版本Apollo，将A云数据全量同步到B云，然后逐步升级B云的Apollo到2.4.0，最后开发切换地址到B云的Apollo，在此期间生产读写的都是A云的Apollo。
优点：避免直接升级A云的Apollo，如果出现故障，影响生产。
缺点：开发切换到B云Apollo时，需要将配置更新到最新。
和方案1对比，是不是更稳妥点呢，谢谢@dosu

[zhuangdl]

@dosu

[dosubot]

方案3（在B云搭建1.3.0 Apollo，同步A云数据，再在B云升级到2.4.0，最后切换到B云）确实比直接在A云升级更稳妥，尤其适合对生产环境影响极度敏感的场景。这样可以把所有升级和测试风险隔离在B云，A云生产完全不受影响。如果升级或数据验证有问题，随时可以回滚或重试，不会影响线上业务。

唯一需要注意的是，切换到B云 Apollo 时，必须确保B云的数据是最新的（可以用全量+增量同步方案），否则配置有丢失风险。切换窗口内建议暂停配置变更，或做好变更同步。

这种“影子环境升级+切换”方式在实际大规模系统迁移和升级中很常见，风险最小，回滚简单。只要同步链路和切换流程可控，就是最安全的做法之一。相关社区讨论也推荐类似思路，强调升级脚本要严格按顺序执行，避免跳步，升级后重启服务，确保缓存一致性参考。

如果还有具体细节想确认，欢迎随时补充！

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[zhuangdl]

方案3（在B云搭建1.3.0 Apollo，同步A云数据，再在B云升级到2.4.0，最后切换到B云）确实比直接在A云升级更稳妥，尤其适合对生产环境影响极度敏感的场景。这样可以把所有升级和测试风险隔离在B云，A云生产完全不受影响。如果升级或数据验证有问题，随时可以回滚或重试，不会影响线上业务。

唯一需要注意的是，切换到B云 Apollo 时，必须确保B云的数据是最新的（可以用全量+增量同步方案），否则配置有丢失风险。切换窗口内建议暂停配置变更，或做好变更同步。

这种“影子环境升级+切换”方式在实际大规模系统迁移和升级中很常见，风险最小，回滚简单。只要同步链路和切换流程可控，就是最安全的做法之一。相关社区讨论也推荐类似思路，强调升级脚本要严格按顺序执行，避免跳步，升级后重启服务，确保缓存一致性参考。

如果还有具体细节想确认，欢迎随时补充！

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other   

谢谢回答

[zhuangdl]

@dosu 你好，安装1.3.0版本时，去哪里获取数据库文件呢，是master分支的这个目录吗？
https://github.com/apolloconfig/apollo/blob/master/scripts/sql/profiles/mysql-default/