黄东旭解析 TiDB 的核心优势
576
2019-10-11
内容来源:http://mp.weixin.qq.com/s?__biz=MzI3NDIxNTQyOQ==&mid=2247489851&idx=1&sn=cd8ca05a07837e73b1f288a63fdb7631&chksm=eb163e51dc61b7473b372c1ed3efd35ee0cb138c81c7a4fa5021c42cc9e159266f743a9c2729#rd
众所周知,PD(github.com/pingcap/pd) 是整个 TiDB 集群的核心,负责全局元信息的存储以及 TiKV 集群负载均衡调度,本文将详细介绍 PD 调度系统的原理,并通过几个典型场景的分析和处理方式,分享调度策略的最佳实践和调优方法,帮助大家在使用过程中快速定位问题。本文内容基于 3.0 版本,更早的版本(2.x)缺少部分功能的支持,但是基本原理类似,也可以以本文作为参考。
PD 调度原理
概念
首先我们介绍一下调度系统涉及到的相关概念,理解这些概念以及它们相互之间的关系,有助于在实践中快速定位问题并通过配置进行调整。
Store
balance-leader-scheduler
:保持不同节点的 Leader 均衡。balance-region-scheduler
:保持不同节点的 Peer 均衡。hot-region-scheduler
:保持不同节点的读写热点 Region 均衡。evict-leader-{store-id}
:驱逐某个节点的所有 Leader。(常用于滚动升级)TransferLeader
:将 Region Leader 迁移至指定 PeerAddPeer
:在指定 Store 添加 FollowerRemovePeer
:删除一个 Region PeerAddLearner
:在指定 Store 添加 Region LearnerPromoteLearner
:将指定 Learner 提升为 FollowerSplitRegion
:将指定 Region 一分为二调度流程
StoreHeartbeat
和 RegionHeartbeat
两种心跳消息。其中 StoreHeartbeat
包含了 Store 的基本信息,容量,剩余空间,读写流量等数据,RegionHeartbeat
包含了 Region 的范围,副本分布,副本状态,数据量,读写流量等数据。PD 将这些信息梳理并转存供调度来决策。OperatorController
管理的一个等待队列。OperatorController
会根据配置以一定的并发从等待队列中取出 Operator 进行执行,执行的过程就是依次把每个 Operator Step 下发给对应 Region 的 Leader。Balance
balance-leader
和 balance-region
这两个调度器,这二者的调度目标是将 Region 均匀地分散在集群中的所有 Store 上。它们的侧重点又有所不同:balance-leader
关注 Region 的 Leader,可以认为目的是分散处理客户端请求的压力;balance-region
关注 Region 的各个 Peer,目的是分散存储的压力,同时避免出现爆盘等状况。balance-leader
与 balance-region
有着类似的调度流程,首先根据不同 Store 的对应资源量的情况分别打一个分,然后不断从得分较高的 Store 选择 Leader 或 Peer 迁移到得分较低的 Store 上。balance-leader
比较简单,使用 Store 上所有 Leader 所对应的 Region Size 加和作为得分;balance-region
由于要考虑不同节点存储容量可能不一致的情况,会分三种情况,当空间富余时使用数据量计算得分(使不同节点数据量基本上均衡),当空间不足时由使用剩余空间计算得分(使不同节点剩余空间基本均衡),处于中间态时则同时考虑两个因素做加权和当作得分。leader-weight
和 region-weight
分别用于控制 leader 权重以及 region 权重,这两个配置的默认值都为 1
。假如把某个 Store 的 leader-weight
设为 2
,调度稳定后,则该节点的 leader 数量约为普通节点的 2 倍;假如把某个 Store 的 region-weight
设为 0.5
,那么调度稳定后该节点的 region 数量约为其他节点的一半。热点调度
hot-region-scheduler
。目前 3.0 版本统计热点 Region 的方式比较单一,就是根据 Store 上报的信息,统计出持续一段时间读或写流量超过一定阈值的 Region,然后再用与 Balance 类似的方式把这些 Region 分散开来。集群拓扑感知
replicaChecker
(跟 Scheduler 类似,但是不可关闭),它依赖于 location-labels
这个配置来进行调度。比如配置 [zone, rack, host]
定义了三层的拓扑结构:集群分为多个 zone(可用区),每个 zone 下有多个 rack(机架),每个 rack 下有多个 host(主机)。PD 在调度时首先会尝试将 Region 的 Peer 放置在不同的 zone,假如无法满足(比如配置 3 副本但总共只有 2 个 zone)则退而求其次保证放置在不同的 rack,假如 rack 的数量也不足以保证隔离,那么再尝试 host 级别的隔离,以此类推。缩容及故障恢复
缩容是指预备将某个 Store 下线,通过命令将该 Store 标记为 Offline
状态,此时 PD 通过调度将待下线节点上的 Region 迁移至其他节点。故障恢复是指当有 Store 发生故障且无法恢复时,有 Peer 分布在对应 Store 上的 Region 会产生缺少副本的状况,此时 PD 需要在其他节点上为这些 Region 补副本。
这两种情况的处理过程基本上是一样的。由 replicaChecker
检查到 Region 存在异常状态的 Peer,然后生成调度在健康的 Store 创建新副本替换掉异常的。
Region merge
mergeChecker
负责,其过程与 replicaChecker
类似,也是在后台遍历,发现连续的小 Region 后发起调度。查询调度状态
Operator 状态
Schedule Operator Create
:展示 Operator 的创建情况,从名称可以知道 Operator 是哪个调度器创建的以及创建的原因。Operator finish duration
:展示了 Operator 执行耗时的情况Operator Step duration
:展示不同 Operator Step 执行耗时的情况operator show
:查询当前调度生成的所有 Operatoroperator show [admin | leader | region]
:按照类型查询 OperatorBalance 状态
Store Leader/Region score
:展示每个 Store 的得分Store Leader/Region count
:展示每个 Store 的 Leader/Region 数量Store available
:展示每个 Store 的剩余空间热点调度状态
Hot write Region’s leader/peer distribution
:展示了写热点 Region 的 Leader/Peer 分布情况Hot read Region’s leader distribution
:展示了读热点 Region 的 Leader 分布情况hot read
:查询读热点 Region 信息hot write
:查询写热点 Region 信息hot store
:按 Store 统计热点分布情况region topread [limit]
:查询当前读流量最大的 Regionregion topwrite [limit]
:查询当前写流量最大的 RegionRegion 健康度
region check miss-peer
:缺副本的 Regionregion check extra-peer
:多副本的 Regionregion check down-peer
:有副本状态为 Down 的 Regionregion check pending-peer
:有副本状态为 Pending 的 Region调度策略控制
启停调度器
scheduler show
:显示当前系统中的 Schedulerscheduler remove balance-leader-scheduler
:删除(停用)balance leader 调度器scheduler add evict-leader-scheduler-1
:添加移除 Store 1 的所有 Leader 的调度器手动添加 Operator
operator add add-peer 2 5
:在 Store 5 上为 Region 2 添加 Peeroperator add transfer-leader 2 5
:将 Region 2 的 Leader 迁移至 Store 5operator add split-region 2
:将 Region 2 拆分为 2 个大小相当的 Regionoperator remove 2
:取消 Region 2 当前待执行的 Operator调度参数调整
config show
命令可以查看所有的调度参数,执行 config set {key} {value}
可以调整对应参数的值。这里举例说明常见的参数,更详情的说明请参考 PD 调度参数指南:leader-schedule-limit
:控制 Transfer Leader 调度的并发数region-schedule-limit
:控制增删 Peer 调度的并发数disable-replace-offline-replica
:停止处理节点下线的调度disable-location-replacement
:停止处理调整 Region 隔离级别相关的调度max-snapshot-count
:每个 Store 允许的最大收发 Snapshot 的并发数典型场景分析与处理
1. Leader / Region 分布不均衡
leader-weight
和 region-weight
来控制 Leader / Region 的分布。leader-schedule-limit
或 region-schedule-limit
调大一些,此外, max-pending-peer-count
以及 max-snapshot-count
限制也可以放宽。region-schedule-limit
配额,此时我们可以把 replica-schedule-limit
调小将下线调度的速度限制住,或者干脆设置 disable-replace-offline-replica = true
来暂时关闭下线流程。TransferLeader
,RemovePeer
,PromoteLearner
等)的完成时间应该在毫秒级,涉及到 Snapshot 的 Step(如 AddLearner
,AddPeer
等)的完成时间为数十秒。如果耗时明显过高,可能是 TiKV 压力过大或者网络等方面的瓶颈导致的,需要具体情况具体分析。0
。evict-leader-scheduler
,此时无法把 Leader 迁移至对应的 Store。再比如设置了 Label property,也会导致部分 Store 不接受 Leader。2. 节点下线速度慢
replica-schedule-limit
,可以把它适当调大。与 Balance 类似,max-pending-peer-count
以及 max-snapshot-count
限制同样也可以放宽。evict-leader
调度迁走 Leader 来加速。replica-schedule-limit
被设为 0。3. 节点上线速度慢
4. 热点分布不均匀
hot-region-schedule-limit
,并减少其他调度器的 limit 配额,从而加快热点调度的速度。还有 hot-region-cache-hits-threshold
调小一些可以使 PD 对流量的变化更快做出反应。split-region
调度将这样的 Region 拆开。scatter-range-scheduler
来使得这个 table 的所有 Region 均匀分布。TiDB 也在其 HTTP API 中提供了相关接口来简化这个操作,具体可以参考 TiDB HTTP API 文档。5. Region Merge 速度慢
merge-schedule-limit
及 region-schedule-limit
),或者是与其他调度器产生了竞争,处理方法不再赘述了。max-merge-region-size
和 max-merge-region-keys
调整为较小值来加快 Merge 速度。这是因为 Merge 的过程涉及到副本迁移,于是 Merge 的 Region 越小,速度就越快。如果 Merge Operator 生成的速度已经有几百 opm,想进一步加快,还可以把 patrol-region-interval
调整为 "10ms" ,这个能加快巡检 Region 的速度,但是会消耗更多的 CPU。false
“”
approximate_keys
在特定情况下(大部分发生在 drop table 之后)统计不准确,造成 keys 的统计值很大,无法满足 max-merge-region-keys
的约束,可以把 max-merge-region-keys
这个条件放开,调成很大的值来绕过这个问题。6. TiKV 节点故障处理策略
max-store-down-time
配置调整),将此节点设置为 Down
状态,并开始为涉及到的 Region 补充副本。max-store-down-time
临时调整为比较大的值,这样能避免超时之后产生不必要的补副本产生资源浪费。总结
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。