TiDB 扩容过程中 PD 生成调度的原理及常见问题丨TiDB 扩缩容指南（一）

TiDB_PingCAP

于 2024-09-14 08:58:46 发布

阅读量778

点赞数 5

文章标签： tidb 数据库

本文链接：https://blog.csdn.net/TiDB_PingCAP/article/details/142246166

版权

导读

作为一个分布式数据库，扩缩容是 TiDB 集群最常见的运维操作之一。本系列文章，我们将基于 v7.5.0 具体介绍扩缩容操作的具体原理、相关配置及常见问题的排查。

通常，我们根据当前资源状态来决定是否需要调整 TiKV 节点的规模，无论是增加还是减少节点。我们希望在调整后，集群能够通过重新调度尽快实现所有在线 TiKV 节点资源的平衡利用。

因此对于扩缩容来说，我们主要关心的还是以下两点：

资源均衡调度指令产生速度(PD 上调度产生的速度 )
资源均衡调度指令执行速度(TiKV 间数据搬迁的速度)

本系列文章将围绕以上两个逻辑，重点介绍扩缩容过程中的核心模块及常见问题，分为以下几个部分：

扩缩容调度生成原理及常见问题：
- 扩容过程中调度生成原理及常见问题
- 缩容过程中调度生成原理及常见问题
扩缩容过程调度执行（TiKV 副本搬迁）的原理及常见问题

本文我们将重点介绍 TiDB 扩容过程中 PD 生成调度的原理和常见问题，希望能够帮助大家更好地理解和运维 TiDB。

扩容过程中 PD 生成调度的原理及常见问题

一般的，当集群中 TiKV 资源跑到 75% 左右时，一般的调优手段无法解决资源使用上的瓶颈，此时，我们就需要通过添加 tikv 节点的方式，来提高集群的整体性能。

通过加节点的方式增加集群相关资源

如图，当集群只有三个 tikv 时，能够使用的存储、CPU 、 memory 到达使用瓶颈时，我们可以通过加节点的方式增加集群相关资源。下面我们简单来看一下，三 tikv 节点下，增加一个 tikv 节点时，TiDB 集群是如何让新节点的物理资源能够被集群使用起来的。首先在三个 TiKV 节点的集群中，在我们 PD 的统一调度下，会尽量将三个 tikv 节点的资源得到均衡使用。

三个 tikv 节点的资源得到均衡使用

新加入一个节点时，PD 会慢慢的将相关数据以 Region 为单位迁移到新节点上，以充分使用新节点的存储、memory 和 CPU 等资源。这当中最重要也是最耗时的就是将 Region 的副本数据从老节点搬迁到新节点上。如下图，PD 将 Region 1 的其中一个副本从 store-3 搬迁到了新节点 store-4 上，这个过程我们叫 balance-region.

balance-region

Balance region 具体步骤

Balance region 以 region 为单位执行，由 PD 计算需要搬迁的 region, 由 TiKV 执行。具体执行过程，简单的来说，主要分为以下三个步骤：

新节点上新增副本 learner 节点（leaner 节点不参与投票过程）。
将新节点的 learner 角色和老节点的 follower 角色互换
将老节点上的副本（learner）删除以上步骤最终会变成一条条调度指令，下发给 KV 去执行，下面我们来看每个调度指令是如何从进行的：

Step1: Add learner

Add learner

PD 中 balance-region-scheduler 生成balance-region operator, 制定具体执行步骤。
PD 通过心跳的方式，告诉 leader 节点执行 add learner peer 操作
Leader 所在节点在这个 Region 的 raft-group 里面广播这个消息，并最终从 leader 上生成 snapshot 发送给 store-4 , 添加 learner 节点完成。
Leader 收到来自 learner 的消息，上报心跳给 PD 告知 add learner 这一步骤执行成功

Step2: Switch role

store-4 上的 learner 节点虽然有完整的数据，但不参与投票过程。我们期望是将 store-3 上的 follower 迁移到 store-4 上，因此，在这一步骤，我们会将 store-4 和 store-3 上的副本的角色互换，最终 store-3 上的老副本会变成 learner, 而新节点上的副本角色变成 voter 也就是 follower.这个过程为了保证数据的安全性，实际情况分为两条调度指令执行。

Switch role