黄东旭解析 TiDB 的核心优势
526
2024-03-28
作者:贲绍华
爱可生研发中心工程师,负责项目的需求与维护工作。其他身份:柯基铲屎官。
本文来源:原创投稿
*爱可生开源社区出品
滚动升级是一种在线升级方式,相比离线升级,滚动升级可保证在部分或全部服务可用的情况下完成软件的升级。在集群规模大且支撑业务多且复杂时,尽量减少业务中断的滚动升级具有重要的意义。
TiUP在升级流程中还有一些细节处理在文中并没有详细书写,本文旨在DBA或开发在升级过程中如果遇问题,可以根据核心流程的解析给与一些帮助与思路。
TiDB 是一款定位于在线事务处理/在线分析处理的融合型数据库产品,实现了一键水平伸缩,强一致性的多副本数据安全,分布式事务,实时 OLAP 等重要特性。同时兼容 MySQL 协议和生态,迁移便捷,运维成本极低。
详细架构见:https://docs.pingcap.com/zh/tidb/stable/tidb-architecture
为了方便下文理解,此处先介绍一下TiDB集群的核心三个组件:
SQL 层,对外暴露 MySQL 协议的连接 endpoint,负责接受客户端的连接,执行 SQL 解析和优化,最终生成分布式执行计划。TiDB 层本身是无状态的,实践中可以启动多个 TiDB 实例,通过负载均衡组件(如 LVS、HAProxy 或 F5)对外提供统一的接入地址,客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据,只是解析 SQL,将实际的数据读取请求转发给底层的存储节点 TiKV(或 TiFlash)。
整个 TiDB 集群的元信息管理模块,负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构,提供 TiDB Dashboard 管控界面,并为分布式事务分配事务 ID。PD 不仅存储元信息,同时还会根据 TiKV 节点实时上报的数据分布状态,下发数据调度命令给具体的 TiKV 节点,可以说是整个集群的“大脑”。此外,PD 本身也是由至少 3 个节点构成,拥有高可用的能力。建议部署奇数个 PD 节点。
负责存储数据,从外部看 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(调度器)是 PD 中生成调度的组件。PD 中每个调度器是独立运行的,分别服务于不同的调度目的。常用的调度器及其调用目标有:
balance-leader-scheduler:保持不同节点的 Leader 均衡。
balance-region-scheduler:保持不同节点的 Peer 均衡。
hot-region-scheduler:保持不同节点的读写热点 Region 均衡。
evict-leader-{store-id}:驱逐某个节点的所有 Leader。(常用于滚动升级)
PD 中的 Store 指的是集群中的存储节点,也就是 tikv-server 实例。Store 与 TiKV 实例是严格一一对应的,即使在同一主机甚至同一块磁盘部署多个 TiKV 实例,这些实例也对会对应不同的 Store。
从 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 server为无状态流量入口组件,部署后会直接在此步骤重启实例进程,相关源码: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服务,不过目前没有写在TiDB官方的手册上,感兴趣的可以了解一下。
详细列表见:https://github.com/tikv/pd/blob/master/server/api/router.go#L130
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。