TiKV 下线状态能否重启整个tidb集群

🪐 TiDB 技术问题 部署&运维管理
, ,
1

您好，当前TiKV处于下线状态中，region 正在迁移，因为cpu 到瓶颈了，我需要重启服务器升级配置，因此我需要停掉整个tidb集群，请问我在升级配置之后启动tidb集群后，下线状态的TiKV 会继续迁移region吗？

{
“store”: {
“id”: 11,
“address”: “172.31.2.241:20160”,
“state”: 1,
“version”: “3.0.2”,
“state_name”: “Offline”
},
“status”: {
“capacity”: “2.9 TiB”,
“available”: “2.4 TiB”,
“leader_count”: 35633,
“leader_weight”: 1,
“leader_score”: 2610240,
“leader_size”: 2610240,
“region_count”: 52928,
“region_weight”: 1,
“region_score”: 3875362,
“region_size”: 3875362,
“start_ts”: “2020-06-21T06:19:18Z”,
“last_heartbeat_ts”: “2020-06-28T08:02:54.419336141Z”,
“uptime”: “169h43m36.419336141s”
}
}

2

你好，

会继续的，正常的关闭集群，此调度会继续执行。

3

当前TiKV处于下线状态中，region 正在迁移,此时我把tidb从3.0 升级到4.0会有影响吗？

4

跨大版本升级，为了稳妥起见，建议调大线程，加速 tikv 下线之后，在进行升级，因为 tidb 目前是不支持降级的，避免出现不必要的问题。

5

目前调整了如下参数，下线的速度还是很慢
config set leader-schedule-limit 32
config set region-schedule-limit 32
config set replica-schedule-limit 64
config set max-pending-peer-count 64
config set max-snapshot-count 64

6
  1. 先检查下 TIKV 磁盘使用是否达到 80% 容量，否则 PD 不会进行补副本操作。
  2. 可以上传下 grafana 监控中 pd 的 scheduler 和 operator 的全部监控项，看下调度的情况。
  3. pd 监控中还有 region health
  4. pd-ctl store 辛苦也返回下，看下当前 offline 节点的 region 和 leader 剩余多少。

以上信息，为了确认当前调度是否正常生成，调度是否正常运行，tikv 容量是否达标。监控时间区间为一天。

7

能否提供一个邮箱地址？我给您生成一个 Grafana 账号，tikv 下线已经6天了还没结束

{
“store”: {
“id”: 10,
“address”: “172.31.26.184:20160”,
“state”: 1,
“version”: “3.0.2”,
“state_name”: “Offline”
},
“status”: {
“capacity”: “2.9 TiB”,
“available”: “2.5 TiB”,
“leader_count”: 16063,
“leader_weight”: 1,
“leader_score”: 1169312,
“leader_size”: 1169312,
“region_count”: 42938,
“region_weight”: 1,
“region_score”: 3153901,
“region_size”: 3153901,
“start_ts”: “2020-06-28T12:36:54Z”,
“last_heartbeat_ts”: “2020-06-29T03:17:39.695314341Z”,
“uptime”: “14h40m45.695314341s”
}
}

{
“store”: {
“id”: 11,
“address”: “172.31.2.241:20160”,
“state”: 1,
“version”: “3.0.2”,
“state_name”: “Offline”
},
“status”: {
“capacity”: “2.9 TiB”,
“available”: “2.4 TiB”,
“leader_count”: 29989,
“leader_weight”: 1,
“leader_score”: 2213460,
“leader_size”: 2213460,
“region_count”: 43147,
“region_weight”: 1,
“region_score”: 3188883,
“region_size”: 3188883,
“start_ts”: “2020-06-28T12:33:11Z”,
“last_heartbeat_ts”: “2020-06-29T03:17:46.985352029Z”,
“uptime”: “14h44m35.985352029s”
}
}

8

ok，已经私信，这边看下

9

谢谢，已回复邮件

10

ok，看下 当前 offline 节点的 leader 比较多，可以在该节点添加 evict leader 调度，转移走上面的 leader 加速调度，先操作并观察下。

  • 下线单个节点时，由于待操作的 Region 有很大一部分（3 副本配置下约 1/3）的 Leader 都集中在下线的节点上，下线速度会受限于这个单点生成 Snapshot 的速度。你可以通过手动给该节点添加一个 evict-leader-scheduler 调度器迁走 Leader 来加速。
11

scheduler add evict-leader-scheduler 11
scheduler add evict-leader-scheduler 10
这样设置吗？

12

https://pingcap.com/docs-cn/stable/pd-control/

可以搜索下

13

已经调整过来， 感觉跟之前没什么变化

14
  1. tiup ctl pd -u http://172.16.4.107:12379 scheduler show 看下
  2. pd-ctl store 11 看下 leader count 是否已经在减少。

PS：邮件这边没有收到，辛苦再看下私信。

15

您好， 如下
“store”: {
“id”: 11,
“address”: “172.31.2.241:20160”,
“state”: 1,
“version”: “3.0.2”,
“state_name”: “Offline”
},
“status”: {
“capacity”: “2.9 TiB”,
“available”: “2.5 TiB”,
“leader_weight”: 1,
“region_count”: 41122,
“region_weight”: 1,
“region_score”: 3044498,
“region_size”: 3044498,
“start_ts”: “2020-06-28T12:33:11Z”,
“last_heartbeat_ts”: “2020-06-29T06:29:58.235764696Z”,
“uptime”: “17h56m47.235764696s”
}
}

###########################################################
{
“store”: {
“id”: 10,
“address”: “172.31.26.184:20160”,
“state”: 1,
“version”: “3.0.2”,
“state_name”: “Offline”
},
“status”: {
“capacity”: “2.9 TiB”,
“available”: “2.5 TiB”,
“leader_count”: 5108,
“leader_weight”: 1,
“leader_score”: 380539,
“leader_size”: 380539,
“region_count”: 41336,
“region_weight”: 1,
“region_score”: 3041577,
“region_size”: 3041577,
“start_ts”: “2020-06-28T12:36:54Z”,
“last_heartbeat_ts”: “2020-06-29T06:40:20.927163837Z”,
“uptime”: “18h3m26.927163837s”
}
}

16

你好

邮件已收到。

  1. 明确下问题，帖子开始 store 11 为 offline，楼上反馈的信息中 store 10 为新增的 offline 节
    点？
  2. 请问下使用 tiup 部署吗，可以上传下 display 看下集群topo，否则可以上传下 inventory 文件。这边看下

此命令信息貌似没有反馈，辛苦执行下，如果是 ansible 部署，可以使用 pd-ctl 来代替

17

您好，store 11 ，store 10 两个都是要下线的，目前是使用asnsible 部署的3.0.2版本
scheduler show如下：
[
“balance-region-scheduler”,
“balance-leader-scheduler”,
“balance-hot-region-scheduler”,
“label-scheduler”,
“evict-leader-scheduler-11”,
“evict-leader-scheduler-10”
]

#######################################
inventory 文件如下：

## TiDB Cluster Part
[tidb_servers]
#172.31.35.127
#172.31.43.8
#172.31.42.205
172.31.42.102
#172.31.16.209
#172.31.11.114
172.31.41.225
172.31.38.159


[tikv_servers]
172.31.42.165
#172.31.38.144
172.31.42.249
172.31.43.197
172.31.2.241
172.31.26.184
172.31.46.18
172.31.38.13

[pd_servers]
172.31.35.127
172.31.43.8
172.31.42.205

[spark_master]

[spark_slaves]

[lightning_server]

[importer_server]

## Monitoring Part
# prometheus and pushgateway servers
[monitoring_servers]
172.31.35.127

[grafana_servers]
172.31.35.127


# node_exporter and blackbox_exporter servers
[monitored_servers]
172.31.42.165
#172.31.38.144
172.31.42.249
172.31.43.197
172.31.2.241
172.31.26.184
172.31.35.127
172.31.43.8
172.31.42.205
172.31.42.102
#172.31.16.209
#172.31.11.114
172.31.46.18
172.31.38.13
172.31.41.225
172.31.38.159


[alertmanager_servers]
172.31.35.127
18

你好，

当前服务器资源不是很一致，所以在调度上速度就会有很大的偏差，当前集群可能是测试集群，为了加速下线，需要调大线程加速下线。

image

保留 evict-leader-scheduler 调度， 尝试将 limit 调大，看是否可以加速迁移。线上环境不建议同时下线 2 个 tikv 节点。
config set leader-schedule-limit 64 先观察下，并通过 sotre 进行查看，是否有减少，再酌情调小或调大，可以在设置该参数之后，观察下调度是否还存在，并且观察 offline 节点的 log 保存记录下来，可用来分析