TiDB 升级方案选择

作者： 啦啦啦啦啦原文来源：https://tidb.net/blog/42a326ae

一. 背景

对于实际维护数据库的 DBA 来说，升级数据库可能会是一个吃力不讨好的工作，因为升级总是一个风险较高的操作，成功了是常规操作，万一出问题了就得背锅。当你想主动推动升级的时候，开发同学可能会说“又不是不能用，已经排了一堆需求了，我们没有时间去测试新版本”，业务的同学可能会说“什么？又要停机，还需要这么长的停机窗口”，领导可能会问“升级能给我们带来什么收益？可不可以不升级？”。

我们为什么要升级数据库？

1. 更多的新特性

2. 更好，更稳定的性能

3. 更好的运维体验

4. 修复数据库 bug 导致的线上问题或者修复一些严重的安全漏洞

5. 跟进官方版本以获取官方或者社区的支持

6. 非技术因素，如公司要求等

前三条很好理解，没有人会嫌一款数据库的功能太多和性能太好，不过这些通常不会是升级的决定性因素。对于一款已经上线很久的系统来说性能和功能一般都足够，开发和领导也不会考虑 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 做实时同步，数据追平后应用流量割接来达到升级的目的

两种升级方式的优劣：

在不考虑成本的情况下，建议优先考虑迁移升级的方式，毕竟有回退方案更放心一点，物理机的话还可以顺便做硬件置换。

使用 tiup 原地升级步骤：

官方文档很详细，这里不做过多赘述，见https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup

迁移升级步骤：

1. 准备工作

1. 新集群拓扑规划（可以和源集群不同）

2. 搭建新版本目标集群

3. 现有生产集群部署 TiDB Binlog 或 TiCDC，搭建正向同步链路

4. 用户迁移，SQL Binding 迁移，定时任务迁移（如定时备份脚本、定时 analyze 脚本等）

5. 使用 sync-diff-inspector 进行源集群和目标集群数据校验（耗时较长，一般以天为单位）

2. 生产系统升级实施（停机窗口内）

1. 停止应用，确认源集群已无应用连接，锁定应用账号

2. 确认数据已追平并在业务切换前关闭正向同步链路

3. 搭建反向同步链路

4. 集群切换（包含域名切换，关闭只读等）

5. 启动应用

6. 业务场景验证

3. 应急回退

1. 若出现短时间无法解决的问题实施回退方案，流量切回老集群

四. 总结

首推迁移升级的方式，跨大版本尤其是跨多个大版本的时候能降低很多未知的风险。即使使用 tiup 升级的方案，建议也提前做好应急预案。以上内容均为个人使用经验，实际升级请以官方文档为主。