技术分享 | TiUP 工具 - TiDB 集群滚动升级核心流程解析

原文来源：https://tidb.net/blog/2e09b2ff

作者：贲绍华

爱可生研发中心工程师，负责项目的需求与维护工作。其他身份：柯基铲屎官。

本文来源：原创投稿

* 爱可生开源社区出品

引言：

滚动升级是一种在线升级方式，相比离线升级，滚动升级可保证在部分或全部服务可用的情况下完成软件的升级。在集群规模大且支撑业务多且复杂时，尽量减少业务中断的滚动升级具有重要的意义。

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 集群滚动升级功能。

四、核心流程解析

1. 配置与参数检查、安装包拉取等（此处略过）

2. 备份旧组件文件， 相关源码： https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/manager/upgrade.go#L140

3. 部署需要升级的组件，TiDB server 为无状态流量入口组件，部署后会直接在此步骤重启实例进程，相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/manager/upgrade.go#L143

4. 升级前置准备：

• 4.1 获取 PD 配置信息，并从 PD 集群中寻找 leader 节点，建立连接

• 4.2 调整 PD 集群参数，增大限制，使其升级 job 调度加速

相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/operation/upgrade.go#L85

1. 构造需要特殊处理的组件 job 清单：

• 将所有特殊组件节点加入清单中（本篇只讲述 TiKV 与 PD 组件），并检测其中 PD 节点是否为 leader，如果是，则安排至最后被处理

• 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/operation/upgrade.go#L119

1. 升级 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

1. 升级 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

1. 回滚 PD 集群 schedule 相关配置

• 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/operation/upgrade.go#L91

1. 保存元数据信息

• 相关源码：https://github.com/pingcap/tiup/blob/9e2e464c362c8604d87a04ff9578e1da7d9b1e64/pkg/cluster/manager/upgrade.go#L237

1. 升级成功

五、其他

版本说明

本文所列举升级流程为 TiUP master 分支最新代码，理论可以适用至最新的 6.x 版本

PD 组件 API

PD 组件定义了很多可以直接管理集群的对外暴露的 API 服务，不过目前没有写在 TiDB 官方的手册上，感兴趣的可以了解一下。

详细列表见：https://github.com/tikv/pd/blob/master/server/api/router.go#L130