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

news2024/11/20 15:41:17

作者：贲绍华

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

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

引言：

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

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
升级成功