作者：贲绍华
爱可生研发中心工程师，负责项目的需求与维护工作。其他身份：柯基铲屎官。
本文来源：原创投稿
*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。
引言：
滚动升级是一种在线升级方式，相比离线升级，滚动升级可保证在部分或全部服务可用的情况下完成软件的升级。在集群规模大且支撑业务多且复杂时，尽量减少业务中断的滚动升级具有重要的意义。
TiUP在升级流程中还有一些细节处理在文中并没有详细书写，本文旨在DBA或开发在升级过程中如果遇问题，可以根据核心流程的解析给与一些帮助与思路。
一、TiDB简介
TiDB 是一款定位于在线事务处理/在线分析处理的融合型数据库产品，实现了一键水平伸缩，强一致性的多副本数据安全，分布式事务，实时 OLAP 等重要特性。同时兼容 MySQL 协议和生态，迁移便捷，运维成本极低。
详细架构见：https://docs.pingcap.com/zh/tidb/stable/tidb-architecture
为了方便下文理解，此处先介绍一下TiDB集群的核心三个组件：
- TiDB Server
SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
- PD (Placement Driver) Server
整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。
- TiKV Server
负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
二、名词解释：
- Scheduler
Scheduler（调度器）是 PD 中生成调度的组件。PD 中每个调度器是独立运行的，分别服务于不同的调度目的。常用的调度器及其调用目标有：
- balance-leader-scheduler：保持不同节点的 Leader 均衡。
- balance-region-scheduler：保持不同节点的 Peer 均衡。
- hot-region-scheduler：保持不同节点的读写热点 Region 均衡。
- evict-leader-{store-id}：驱逐某个节点的所有 Leader。（常用于滚动升级）
- Store
PD 中的 Store 指的是集群中的存储节点，也就是 tikv-server 实例。Store 与 TiKV 实例是严格一一对应的，即使在同一主机甚至同一块磁盘部署多个 TiKV 实例，这些实例也对会对应不同的 Store。
三、TiUP工具简介
从 TiDB 4.0 版本开始，TiUP 作为新的工具，承担着包管理器的角色，管理着 TiDB 生态下众多的组件，如 TiDB、PD、TiKV 等。用户想要运行 TiDB 生态中任何组件时，只需要执行 TiUP 一行命令即可，相比以前，极大地降低了管理难度。其中就包括了本篇要讲述的TiDB集群滚动升级功能。
四、核心流程解析
- 配置与参数检查、安装包拉取等（此处略过）
- 备份旧组件文件 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/manager/upgrade.go#L140
- 部署组件 TiDB组件为无状态流量入口，部署后会直接在此步骤重启实例进程 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/manager/upgrade.go#L143
- 升级前置准备： 4.1 获取PD配置信息，并从PD集群中寻找leader节点，建立连接 4.2 调整PD集群参数，增大限制，使其升级job调度加速
schedule.leader-schedule-limit # 可以控制同时进行 leader 调度的任务个数 如果当前该配置项值小于64，则调整为：当前配置值+64 schedule.region-schedule-limit # 可以控制同时进行 Region 调度的任务个数 如果当前该配置项值小于1024，则调整为：当前值+1024 详细介绍见：https://docs.pingcap.com/zh/tidb/stable/dynamic-config#在线修改-pd-配置
相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/operation/upgrade.go#L85
- 构造需要特殊处理的组件job清单： 将所有特殊组件节点加入清单中（本篇只讲述TiKV与PD组件），并检测其中PD节点是否为leader，如果是，则安排至最后被处理 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/operation/upgrade.go#L119
- 升级TiKV集群： 6.1 检测PD leader是否存活 6.2 记录TiKV store leader信息 为了接下来驱逐leader做准备 6.3 [PD API Client] 创建store驱逐者 驱逐者会踢掉当前的store leader 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/spec/tikv.go#L336 6.4 重启TiKV实例进程 6.5 [PD API Client] 移除store驱逐者 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/spec/tikv.go#L379
- 升级PD集群 7.1 检查当前升级节点是否为PD leader，如果是则驱逐该leader。 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/spec/pd.go#L353 7.2 重启PD实例进程 7.3 [PD API Client] PD集群健康状态检查 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/spec/pd.go#L379
- 回滚PD集群schedule相关配置 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/operation/upgrade.go#L91
- 保存元数据信息 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/manager/upgrade.go#L237
- 升级成功
五、其他
版本说明
本文所列举升级流程为TiUP master分支最新代码，理论可以适用至最新的6.x版本
PD组件API
PD组件定义了很多可以直接管理集群的对外暴露的API服务，不过目前写在TiDB官方的手册上，感兴趣的可以了解一下。
详细列表见：https://github.com/tikv/pd/blob/master/server/api/router.go#L130