TiDB 数据库调度(PD)揭秘

一、PD 简介

1.1 元数据管理

1.2 调度决策

1.3 全局服务

一、PD 简介

TiDB PD (Placement Driver) 是 TiDB 分布式数据库系统中的核心组件之一，负责整个集群的元数据管理和调度工作。PD 在 TiDB 架构中扮演着至关重要的角色，确保了数据的正确分布、高可用性、以及资源的有效利用。

PD 的功能如下：

1.1 元数据管理

存储集群全局元信息：PD 保存了 TiKV 集群的整体拓扑结构、每个 TiKV 节点的状态、以及数据在各个节点上的分布情况（即 Region 分布）等关键元数据。

维护 Region 信息：Region 是 TiKV 中数据的最小分布单元，PD 负责记录每个 Region 的键值范围、副本位置、Leader 信息等，并动态调整 Region 分布以实现数据均衡。

1.2 调度决策

数据均衡：PD 根据预设的策略（如 Region 大小、副本数、地域分布等）定期进行数据均衡操作，通过迁移 Region 的副本来避免数据热点、保证资源利用率，并确保在节点故障时有足够的副本可用。

故障恢复：当 TiKV 节点发生故障或网络隔离时，PD 负责检测并触发故障转移流程，重新选举 Leader，确保数据的高可用性。

Region Split/Merge：根据数据增长和查询需求，PD 自动触发 Region 的分裂（Split）和合并（Merge）操作，以维持合理的 Region 大小，优化查询性能。

1.3 全局服务

全局唯一时间戳（Timestamp Oracle, TSO）：PD 提供全局单调递增的时间戳服务，用于协调分布式事务中的时间顺序，确保事务的 ACID 特性。

全局唯一 ID 分配：PD 分配全局唯一的 Region ID、Table ID、Index ID 等，确保在整个集群内标识符的唯一性。

1.4 集群配置与管理

配置变更：PD 存储并管理 TiKV、TiDB 等组件的配置信息，支持动态调整配置并通过 gRPC 接口推送变更。

监控与告警：PD 收集集群的运行状态和性能指标，支持通过 Prometheus 等工具进行监控，并提供告警功能。

Dashboard & CLI：提供图形化界面（TiDB Dashboard）和命令行工具（pd-ctl）供管理员查看集群状态、执行管理操作。

二、TiKV 管理

TiKV 集群是 TiDB 数据库的分布式 KV 存储引擎，数据以 Region 为单位进行复制和管理，每个 Region 会有多个副本 (Replica)，这些副本会分布在不同的 TiKV 节点上，其中 Leader 负责读/写，Follower 负责同步 Leader 发来的 Raft log。

需要考虑一下场景：

为了提高集群的空间利用率，需要根据 Region 的空间占用对副本进行合理的分布。
集群进行跨机房部署时，要保证一个机房掉线，不对丢失 Raft Group 的多个副本。
添加一个新的 TiKV 节点时，需要合理的将集群中其他节点上的数据搬到新节点上。
当一个节点掉线时，需要考虑快速的容灾。
并不是所有的 Region 都被频繁的访问，可能访问热点只在少数几个 Region，需要通过调度进行负载均衡。

以上问题和场景如果多个同时出现，就不太容易解决，因为需要考虑全局信息。同时整个系统也是在动态变化的，因此需要一个中心节点，来对系统的整体状况进行把控和调整，所以有了 PD 这个模块。

2.1 调度需求

对以上问题进行分类和整理，可以分为两个问题：

1. 作为一个分布式高可用系统，必须满足以下要求

副本数量要合适，不能多也不能少
副本要均匀的分布在不同的机器上
节点宕机能够自动合理的进行容灾

2. 作为一个良好的分布式系统，要考虑的方面如下

维持整个 Leader 分布均匀
维持每个节点存储容量均匀
维持访问热点数据均匀
控制负载均衡
管理节点状态，包括手动上线\下线节点

满足第一类需求后，整个系统将具备强大的容灾功能。满足第二类需求后，可以使得系统整体的资源利用率更高且合理，具备良好的扩展性。

为了满足这些需求，首先需要收集足够的信息，比如每个节点的状态、每个 Raft Group 的信息、业务访问操作的统计等；其次需要设置一些策略，PD 根据这些信息以及调度的策略，制定出尽量满足前面所述需求的调度计划；最后需要一些基本的操作，来完成调度计划。

2.2 信息收集

调度依赖于整个集群的信息收集，简单来说，调度需要知道每个 TiKV 节点的状态以及每个Region 的状态。TiKV 集群会向PD汇报两类信息，TiKV 节点信息和 Region 信息。每个 TiKV 节点会定期向 PD 汇报节点的状态信息。

TiKV节点(Store)与PD之间存在心跳包，一方面PD通过心跳包检测每个Store是否存活，以及是否有新加入的Store；另一方面心跳包也会携带这个Store的状态信息，主要包括：

总磁盘容量
可用磁盘容量
承载的 Region 数量
数据写入/读取速度
发送/接收的 Snapshot 数量(副本之间可能会通过 Snapshot 同步数据)
是否过载
labels标签信息

TiKV Store 的状态具体分为 Up，Disconnect，Offline，Down，Tombstone。各状态的关系如下：

Up：表示当前的 TiKV Store 处于提供服务的状态。

Disconnect：当 PD 和 TiKV Store 的心跳信息丢失超过 20 秒后，该 Store 的状态会变为 Disconnect 状态，当时间超过 max-store-down-time 指定的时间后，该 Store 会变为 Down 状态。

Down：表示该 TiKV Store 与集群失去连接的时间已经超过了 max-store-down-time 指定的时间，默认 30 分钟。超过该时间后，对应的 Store 会变为 Down，并且开始在存活的 Store 上补足各个 Region 的副本。

Offline：当对某个 TiKV Store 通过 PD Control 进行手动下线操作，该 Store 会变为 Offline 状态。该状态只是 Store 下线的中间状态，处于该状态的 Store 会将其上的所有 Region 搬离至其它满足搬迁条件的 Up 状态 Store。当该 Store 的 leader_count 和 region_count (在 PD Control 中获取) 均显示为 0 后，该 Store 会由 Offline 状态变为 Tombstone 状态。在 Offline 状态下，禁止关闭该 Store 服务以及其所在的物理服务器。下线过程中，如果集群里不存在满足搬迁条件的其它目标 Store（例如没有足够的 Store 能够继续满足集群的副本数量要求），该 Store 将一直处于 Offline 状态。

Tombstone：表示该 TiKV Store 已处于完全下线状态，可以使用 remove-tombstone 接口安全地清理该状态的 TiKV。

每个 Raft Group 的 Leader 会定期向 PD 汇报 Region 状态。每个 Raft Group 的 Leader 和 PD 之间存在心跳包，用户汇报 Region 状态，主要包括以下信息：

Leader的位置
Follwers的位置
掉线副本个数
数据写入读取速度

PD 不断的通过这两类心跳消息收集整个集群的信息，再以这些信息作为决策的依据。

除此之外，PD 还可以通过扩展的接口接受额外的信息，用来做更准确的决策。比如当某个 Store 的心跳包中断的时候，PD 并不能判断这个节点是临时失效还是永久失效，只能经过一段时间的等待（默认是 30 分钟），如果一直没有心跳包，就认为该 Store 已经下线，再决定需要将这个 Store 上面的 Region 都调度走。

三、TiDB server 管理

PD 如何管理和监控 TiDB Server，一下是主要内容：

元数据管理：PD 维护整个 TiDB 集群的元数据信息，包括 TiDB Server 节点的列表、状态、配置等。这些信息用于确保 PD 能够准确地知道哪些 TiDB Server 正在运行，以及它们的网络地址、角色（如普通 TiDB Server、TiFlash 服务等）等属性。
调度决策：PD 根据收集到的集群状态信息进行智能调度，如负载均衡、故障转移等。如果发现某个 TiDB Server 负载过高或出现故障，PD 会触发相应的调度策略，如将部分 SQL 查询重定向到其他负载较低的 TiDB Server，或者在故障恢复后重新分配 Region 到恢复的节点上。
配置推送：PD 可以向 TiDB Server 推送全局或局部的配置变更，如系统参数调整、新功能开关等。TiDB Server 会定期从 PD 获取并应用这些配置更新，确保整个集群的配置一致性。
心跳检测与健康检查：TiDB Server 定期向 PD 发送心跳信息，报告自己的存活状态和负载情况。PD 通过接收和解析这些心跳消息来监控 TiDB Server 的健康状况。如果某个 TiDB Server 在一段时间内未发送心跳，PD 会认为该节点可能存在问题，并采取相应措施（如标记为下线、重新调度其负责的负载等）。
全局事务协调：PD 分配全局唯一且递增的事务ID给 TiDB Server，用于协调分布式事务。TiDB Server 在发起事务时需要从 PD 获取事务ID，确保事务的全局唯一性和时间顺序。