uptool修改文件量产 ()

作者:贲绍华


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


本文来源:原创投稿


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

引言:

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

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,则调整为:当前配置值+64schedule.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