作者： WalterWj 原文来源：https://tidb.net/blog/663b462e

数据库升级原则

场景 1：当前版本已经超过厂商产品支持周期

运维组会主动告知项目 / 业务组，当前数据库已经超过原厂数据版本维护周期，告知风险：数据库不再提供问题修复新补丁，短期无法解决，需要升级解决。如果项目 / 业务组判断业务代码不再有修改，风险较低，无需升级。其中风险项目 / 业务组进行承担。

场景 2：有重大 BUG

运维组发现当前版本有重大 bug，会影响：结果正确性、数据可用性等。导致数据库不可用的情况下，会主动推进升级事项

场景 3：项目组主动推动升级

当项目 / 业务组明确需要产品升级，满足一些性能 / 功能需求，则可以主动发起升级请求。

数据库升级流程

其他说明

测试

1. 原则上要求进行非功能测试

2. 条件有限情况下至少完成功能测试

额外补充：测试一般时间较久，一般 3~12 月左右。

版本回退

1. 备份还原方式：接受长时间停机的情况下，升级后，如果发现问题，可以全量备份还原方式将数据库降级回原版本

2. 主从方式：接受短时间停机的情况下，申请新的服务器资源后搭建主从迁移方式进行升级。

3. 原数据库版本回退：需要数据库支持原地版本回退功能。