TIDB-扩缩容问题

一、扩容

扩容遇到问题比较少，这里不详细说 

二、缩容

缩容不成功的时候可以采取--force强制缩容（尽量不要使用，除非以下操作不管用）

pd相关操作：

2.1 缩容pd报错xxx faild to stop

1. 检查出错节点端口是否存在，ss -ltn，确定关闭之前需要确认是否为当前集群的服务，避免影响其他集群。
2. 检查出错节点服务是否存在，有则可通过 systemctl 关闭，或者 kill
3. 可以使用 --wait-timeout 参数增加等待时间

我这里报错的原因是因为机器上用systemctl起了一个9100的端口，所以9100一直关不掉，导致的缩容不成功，去到对应的机器上用systemctl stop node_exporter即可正常缩容

2.2 缩容pd leader的保险做法

使用pd-ctl将pd的leader转移到其他的pd上，然后再进行缩容

# 查看成员信息
member
# 查看pd leader
member leader show
# 将pd leader从当前成员迁移走
member leader resign
# 迁移pd leader到对应的pd上
member leader transfer pd3

tikv相关操作

1. 缩容长期处于pending offline的状态

可能是由于pd的调度过慢

进入pd交互界面

tiup ctl:v4.0.13 pd -i -u http://pd_ip:pd_port

查看对应的store情况

# 如果不知道具体的store_id，直接输入store查看
store store_id

如果确实是调度慢则可以调整具体参数

config set schedule.leader-schedule-limit 16

# 以下几个参数的调整都会适当改变调度的速度
# max-pending-peer-count 控制单个 store 的 pending peer 上限，调度受制于这个配置来防止在部分节点产生大量日志落后的 Region。
# leader-schedule-limit  同时进行 leader 调度的任务个数
# region-schedule-limit  同时进行 Region 调度的任务个数
# max-snapshot-count     控制单个 store 最多同时接收或发送的 snapshot 数量，调度受制于这个配置来防止抢占正常业务的资源。
# replica-schedule-limit 同时进行 replica 调度的任务个数

如果速度还是慢则可以先将下线的tikv的leader先手动驱出
scheduler add evict-leader-scheduler 4  # 添加移除 Store 4 的所有 Leader 的调度器

#如果上面都做了还是慢，可以观察对业务的影响使用store limit
store limit 20
# 官网链接：https://docs.pingcap.com/zh/tidb/v4.0/configure-store-limit

具体影响参数可以查看官网：PD 调度策略最佳实践 | PingCAP Docs

在缩容集群时，对于某些组件（tikv,tiflash等），并不会立即停止服务并删除数据，而是需要等数据调度完成之后（状态变为Tombstone），用户手动执行 tiup cluster prune  {集群名} 命令清理。

缩容完成后有可能grafana会出现下图所示的问题

用下面的方法解决：

# 方法一、pd-ctl中执行
store remove-tombstone 
# 方法二、还未测试
curl -X DELETE pd-addr:port/pd/api/v1/stores/remove-tombstone