## 模块 4: 对 TiKV 集群进行缩容 + 本模块中，参与者手动为 TiKV 集群减少一个 TiKV 节点来进行缩容。之后参与者会在下一个模块对缩容的速率进行控制。 ### 步骤 1. 将所有 TiKV 节点的 `store limit` 的项目设置为 `1` + 切换至[终端 1](ssh://monitor1-ssh#1)，将所有 TiKV 节点的 `store limit` 的项目设置为 `1`。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit all 1 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit all 1 Success! Set store limit successfully. ``` + 确认所有 TiKV 节点的 `store limit` 的所有项目已经被设置为 `1`。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit { "1": { "add-peer": 1, "remove-peer": 1 }, "4": { "add-peer": 1, "remove-peer": 1 }, "576": { "add-peer": 1, "remove-peer": 1 }, "7": { "add-peer": 1, "remove-peer": 1 } } ``` ### 步骤 2. 从集群中删除一个 TiKV 服务器 + 在[终端 1](ssh://monitor1-ssh#1) 中，随机删除一个TiKV服务器，缩减存储层。 ```bash RANDOM_TIKV_NODE=`~/.tiup/bin/tiup cluster display tidb-demo | grep 20160 | sed 's/ .*$//' | head -n 1` ~/.tiup/bin/tiup cluster scale-in tidb-demo --node ${RANDOM_TIKV_NODE} -y ``` ```output ... Scaled cluster `tidb-demo` in successfully ``` + 销毁已删除的TiKV节点。 ```bash ~/.tiup/bin/tiup cluster prune tidb-demo -y ``` ```output ... Destroy success ``` + 确认 TiDB 集群状态，此时会发现删除的 TiKV 节点处于 `Pending Offline` 状态，原因是该节点上的 region 并没有全部被移除。 ```bash ~/.tiup/bin/tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.74.236.1:2379/dashboard Grafana URL: http://10.90.4.196:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.196:9093 alertmanager 10.90.4.196 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.196:3000 grafana 10.90.4.196 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.178:2379 pd 10.90.2.178 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.196:9090 prometheus 10.90.4.196 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.140:4000 tidb 10.90.1.140 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.169:20160 tikv 10.90.1.169 20160/20180 linux/x86_64 Pending Offline /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.192:20160 tikv 10.90.1.192 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.88:20160 tikv 10.90.1.88 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.99:20160 tikv 10.90.1.99 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.4.196:6000 tiproxy 10.90.4.196 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000 Total nodes: 10 ``` + 回到 [Grafana 监控](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) 的 `tidb-demo-PD`，在`tidb-demo-PD`上半部分，可以看到 `Offline store progress`，`Left time` 和 `Current scaling speed` 均有数值。 这表示缩容正在进行，接下来需要调高缩容的速率。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/651768f831fc8f0850c53a533ab4529e3908197f.png) ### 步骤 3. 对 TiKV 集群的缩容进行加速 + 在`tidb-demo-PD`上半部分，等待 `Offline store progress` 超过 10% 后（注意：建议在 `Offline store progress` 为 10% 到 20% 间开启此步骤， 因为如果超过 20%， 可能没有时间进行之后的步骤）, 将所有 TiKV 节点的 `store limit` 的项目设置为 `5` 来提高 TiKV 执行 Operator 的速率。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit all 5 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit all 5 Success! Set store limit successfully. ``` + 确认所有 TiKV 节点的 `store limit` 的项目已经被设置为 `5`。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit { "1": { "add-peer": 5, "remove-peer": 5 }, "4": { "add-peer": 5, "remove-peer": 5 }, "576": { "add-peer": 5, "remove-peer": 5 }, "7": { "add-peer": 5, "remove-peer": 5 } } ``` + 等待 10 秒，在`tidb-demo-PD` 的 `Operator` 标签，可以看到 `Scheduler operator create` 面板和 `Scheduler operator finish` 面板中 `replace-rule-offline-peer` 和 `replace-rule-offline-leader-peer` 的速率开始上升，这是因为 TiKV 执行 Operator 的效率变高， 注意这两个 operator 是缩容时 PD 发出的对平衡起主要作用的 operator。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/90df54268d6aa8fa0c85a20c8baada857e155668.png) + 在 `tidb-demo-TiKV-Details` 的 `Cluster` 标签，可以看到各个 TiKV 节点的 IO 使用率 `IO utillzation` 开始上升， 这也表示新加入的 TiKV 节点和被选为源的 TiKV 节点会将 IO 资源用在缩容上， 这有可能会对现有的业务负载造成影响。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/b8369458e4f86946c674b3645dccebf788208b19.png) + 等待，观察在`tidb-demo-PD`上半部分，可以看到 `Offline store progress` 的百分比在加快上升，`Left time` 的数值在变小， `Current scaling speed` 上升。 这表示 Store limit 的增加可以加快缩容的速率。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/43df4c4872c1c59b15f220118a4e42f865d76e62.png) ### 步骤 4. 对 TiKV 集群的缩容进行减速 + 在`tidb-demo-PD`上半部分，等待 `Offline store progress` 超过 50% 后（注意：建议在 `Offline store progress` 为 50% 到 60% 间开启此步骤， 因为如果超过 60%， 可能没有时间进行之后的步骤）, 将所有 TiKV 节点的 `store limit` 的项目设置为 `1` 来降低 TiKV 执行 Operator 的速率。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit all 1 ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit all 1 Success! Set store limit successfully. ``` + 确认所有 TiKV 节点的 `store limit` 的所有项目已经被设置为 `1`。 ```bash ~/.tiup/bin/tiup ctl:v${LAB:TIDB_VERSION} pd -u http://${HOST_PD1_PRIVATE_IP}:2379 store limit ``` ```output Starting component ctl: /home/ec2-user/.tiup/components/ctl/v${LAB:TIDB_VERSION}/ctl pd -u http://10.90.2.178:2379 store limit { "1": { "add-peer": 1, "remove-peer": 1 }, "4": { "add-peer": 1, "remove-peer": 1 }, "576": { "add-peer": 1, "remove-peer": 1 }, "7": { "add-peer": 1, "remove-peer": 1 } } ``` + 回到 [Grafana 监控](http://${LAB:HOST_MONITOR1_PUBLIC_IP}:3000) 的 `tidb-demo-PD`，等待 10 秒，在`tidb-demo-PD` 的 `Operator` 标签，可以看到 `Scheduler operator create` 面板和 `Scheduler operator finish` 面板中 `replace-rule-offline-peer` 和 `replace-rule-offline-leader-peer` 的速率开始下降，这是因为 TiKV 执行 Operator 的效率变低。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/406021a71460034ad668fcf176f750098ed8175b.png) + 在 `tidb-demo-TiKV-Details` 的 `Cluster` 标签，可以看到各个 TiKV 节点的 IO 使用率 `IO utillzation` 开始下降， 这也表示 TiKV 集群会将少量 IO 资源用在缩容， 这可能会避免对现有的业务负载造成影响，但缩容会变得缓慢。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/214390b37261a4bf2e4dacca120f9382a7dad6f7.png) + 等待，观察在`tidb-demo-PD`上半部分，可以看到 `Online store progress` 的百分比上升速度开始变慢，`Left time` 的数值在变长， `Current scaling speed` 开始下降。 这表示 Store limit 的降低可以减慢缩容的速率。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/e31ebaa56b7d09b7720cd0cd9123c91550186a90.png) ### 步骤 5. 等待 TiKV 集群缩容过程的平衡完成，并销毁节点 + 继续等待，并观察在`tidb-demo-PD`上半部分的 `Offline store progress`，`Left time` 和 `Current scaling speed` 的变化，直到 `Offline store progress` 为 `No data`, 表示缩容正式完成。注意：如果参与者认为缩容过于缓慢，可以尝试将 `store limit` 调整为 `20` 来加快缩容操作的完成。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/3b911baaaa83ac8dbb10dee3181fa6613f721bf9.png) + 当 `Offline store progress` 达到 90% 以上时， `Current scaling speed` 持续变低。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/32f4cef10c31bc4456d01881deeec463eb6153e6.png) + 当 `Offline store progress` 为 `No Data` 时， 表示缩容过程的平衡阶段完毕。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/127c33db5b21e0c16ee8d35d248dbb880e7be75d.png) + 在`tidb-demo-PD`下半部分的 `Statistics - balance` 标签，可以看到 `Store available` 面板和 `Store available ratio`面板表示了缩容后 TiKV 集群的数据分布情况。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/4a584f550935b2f764f27aac55d44c25942bbcc1.png) + 在 `tidb-demo-TiKV-Details` 的 `Cluster` 标签找到 `IO utillzation` 面板，放大时间范围到整个缩容的过程， 会发现 TiKV 集群的负载情况根据 `store limit` 值进行变化。 ![70%](https://lab-static.pingcap.com/images/2025/7/24/2e6a23f3e643340053b5b2ae9db2fe3181b9fb92.png) + 确认 TiDB 集群状态，此时会发现删除的 TiKV 节点处于从 `Pending Offline` 状态变为 `Tombstone` 状态， 说明其上的 Region 已经被迁移， 并可以进行 `prune` 操作。 ```bash ~/.tiup/bin/tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.74.236.1:2379/dashboard Grafana URL: http://10.90.4.196:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.196:9093 alertmanager 10.90.4.196 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.196:3000 grafana 10.90.4.196 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.178:2379 pd 10.90.2.178 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.196:9090 prometheus 10.90.4.196 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.140:4000 tidb 10.90.1.140 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.169:20160 tikv 10.90.1.169 20160/20180 linux/x86_64 Tombstone /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.192:20160 tikv 10.90.1.192 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.88:20160 tikv 10.90.1.88 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.99:20160 tikv 10.90.1.99 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.4.196:6000 tiproxy 10.90.4.196 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000 Total nodes: 10 There are some nodes can be pruned: Nodes: [10.90.1.169:20160] You can destroy them with the command: `tiup cluster prune tidb-demo` ``` + 销毁已删除的TiKV节点。 ```bash ~/.tiup/bin/tiup cluster prune tidb-demo -y ``` ```output ... Destroy success ``` + 确认 TiDB 集群状态，发现缩容操作完毕。 ```bash ~/.tiup/bin/tiup cluster display tidb-demo ``` ```output Cluster type: tidb Cluster name: tidb-demo Cluster version: v${LAB:TIDB_VERSION} Deploy user: ec2-user SSH type: builtin Dashboard URL: http://35.74.236.1:2379/dashboard Grafana URL: http://10.90.4.196:3000 ID Role Host Ports OS/Arch Status Data Dir Deploy Dir -- ---- ---- ----- ------- ------ -------- ---------- 10.90.4.196:9093 alertmanager 10.90.4.196 9093/9094 linux/x86_64 Up /tidb-data/alertmanager-9093 /tidb-deploy/alertmanager-9093 10.90.4.196:3000 grafana 10.90.4.196 3000 linux/x86_64 Up - /tidb-deploy/grafana-3000 10.90.2.178:2379 pd 10.90.2.178 2379/2380 linux/x86_64 Up|L /tidb-data/pd-2379 /tidb-deploy/pd-2379 10.90.4.196:9090 prometheus 10.90.4.196 9090/12020 linux/x86_64 Up /tidb-data/prometheus-9090 /tidb-deploy/prometheus-9090 10.90.1.140:4000 tidb 10.90.1.140 4000/10080 linux/x86_64 Up - /tidb-deploy/tidb-4000 10.90.1.192:20160 tikv 10.90.1.192 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.88:20160 tikv 10.90.1.88 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.1.99:20160 tikv 10.90.1.99 20160/20180 linux/x86_64 Up /tidb-data/tikv-20160 /tidb-deploy/tikv-20160 10.90.4.196:6000 tiproxy 10.90.4.196 6000/3080 linux/x86_64 Up - /tidb-deploy/tiproxy-6000 Total nodes: 9 ```