一.背景
对于实际维护数据库的 DBA 来说，升级数据库可能会是一个吃力不讨好的工作，因为升级总是一个风险较高的操作，成功了是常规操作，万一出问题了就得背锅。当你想主动推动升级的时候，开发同学可能会说“又不是不能用，已经排了一堆需求了，我们没有时间去测试新版本”，业务的同学可能会说“什么？又要停机，还需要这么长的停机窗口”，领导可能会问“升级能给我们带来什么收益？可不可以不升级？”。
我们为什么要升级数据库？
- 更多的新特性
- 更好，更稳定的性能
- 更好的运维体验
- 修复数据库 bug 导致的线上问题或者修复一些严重的安全漏洞
- 跟进官方版本以获取官方或者社区的支持
- 非技术因素，如公司要求等
前三条很好理解，没有人会嫌一款数据库的功能太多和性能太好，不过这些通常不会是升级的决定性因素。对于一款已经上线很久的系统来说性能和功能一般都足够，开发和领导也不会考虑 DBA 的运维体验是否足够好。核心系统主要还是后 3 个因素决定是否升级，bug 和漏洞自不用多说，逼不得以必须要升级。如果生产环境和官方最新版本时间跨度太长，不管是社区版还是尊贵的 VIP 付费客户，出问题后可能没有人能够解决或者解决问题的周期会更长，而这些问题很可能早就在新版本中解决了。有人可能会说，MySQL 5.7，5.6 不还是有大把的人在用，我觉得是因为本身国内很少有 MySQL 的付费用户，反正是否 EOL 都没有官方支持，另外 MySQL 有大量的实践案例和文档，有大量精通 MySQL 的从业人员，即使出问题也基本都能解决。Asktug 是我见过最活跃的开源社区，你所发出的帖子一般都能得到社区小伙伴的有效回应，但是偶尔还是会有人发 4.0，3.0 甚至 2.1 版本 TiDB 问题的帖子，这些帖子大多都很难给出合适的解决方案，除了升级之外别无他法。
二.版本选择
TiDB 是一款版本迭代很快的数据库产品，现在差不多每半年就会发布一个新的 LTS 版本，而这款新的 LTS 版本距离 EOL 还有 4 年时间，因此如果想要每次升级都赶在 EOL 之前，最晚每 4 年就要升级一次。实际情况可能是，生产环境通常会选择次新大版本的最新小版本，比如目前最新的 LTS 版本是 7.5.1，那我们选择升级的目标版本可能会是7.1.5，确定版本之后再基于该版本进行严格的业务测试（核心系统至少3个月以上），等到真正升级的时候可能距离 EOL 三年左右。
三.升级方案选择
TiDB 升级一般有两种方案:
- 使用 tiup 原地升级：通过升级 tidb 组件的二进制文件和执行脚本来达到升级的目的
- 迁移升级：搭建一套新版本的 tidb 集群，使用 TiCDC 或 TiDB Binlog 做实时同步，数据追平后应用流量割接来达到升级的目的
两种升级方式的优劣：
| 升级方案 | 优势 | 劣势 |
|---|---|---|
| 原地升级 | 升级方式简单 不需要额外的硬件 |
业务影响时间相对较长，虽然可以选择停机升级和不停机升级，但核心系统还是建议停机操作 不支持回退 不停机升级可能会有性能抖动 保证升级过程中无用户发起的 DDL 操作（升级前为 7.1 之前的版本） 不支持将 TiFlash 组件从 5.3 之前的老版本在线升级至 5.3 及之后的版本，只能采用停机升级 版本跨度过大时，如 3.0 升级7.1，需先升级到 4.0，比较繁琐 |
| 迁移升级 | 业务影响时间短 不受版本跨度限制 可以回退 |
需要至少额外 1:1 的硬件，成本高，若采购硬件周期长 若数据量巨大，全量同步数据耗时长，GC 可能需要调整 TiCDC 或 TiDB Binlog 同步增量数据表必须有主键或者唯一键 |
在不考虑成本的情况下，建议优先考虑迁移升级的方式，毕竟有回退方案更放心一点，物理机的话还可以顺便做硬件置换。
使用 tiup 原地升级步骤：
官方文档很详细，这里不做过多赘述，见https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup
迁移升级步骤：
1.准备工作
- 新集群拓扑规划（可以和源集群不同）
- 搭建新版本目标集群
- 现有生产集群部署 TiDB Binlog 或 TiCDC，搭建正向同步链路
- 用户迁移，SQL Binding迁移，定时任务迁移（如定时备份脚本、定时 analyze 脚本等）
- 使用 sync-diff-inspector 进行源集群和目标集群数据校验（耗时较长，一般以天为单位）
2.生产系统升级实施（停机窗口内）
- 停止应用，确认源集群已无应用连接，锁定应用账号
- 确认数据已追平并在业务切换前关闭正向同步链路
- 搭建反向同步链路
- 集群切换（包含域名切换，关闭只读等）
- 启动应用
- 业务场景验证
3.应急回退
- 若出现短时间无法解决的问题实施回退方案，流量切回老集群
四.总结
首推迁移升级的方式，跨大版本尤其是跨多个大版本的时候能降低很多未知的风险。即使使用 tiup 升级的方案，建议也提前做好应急预案。以上内容均为个人使用经验，实际升级请以官方文档为主。
