tidb-v3.0.9集群中的一台tikv关机维护

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
tipd三台+tidb 3台 + tikv 3台的集群(v3.0.9版本)

【概述】 场景 + 问题概述
现在其中一台tikv内存告警,需要关机维护 ,这台tikv在关机前要如何操作?是在中控机上直接关掉tikv的服务,还是说要将这台有故障的tikv从集群中缩容的方式删除,处理好后再扩容回去?

【问题】 当前遇到的问题
现在其中一台tikv内存告警,需要关机维护 ,这台tikv在关机前要如何操作?是在中控机上直接关掉tikv的服务,还是说要将这台有故障的tikv从集群中缩容的方式删除,处理好后再扩容回去?
这本来应该是很简单的事,但我看网上与论坛没有这方面的维护文档,麻烦大家分享下有无相似的处理过程,多谢。
【业务影响】
暂无
【TiDB 版本】
V3.0.9

用扩缩容的方式,不要直接kill tikv-server https://docs.pingcap.com/zh/tidb/v3.0/scale-tidb-using-ansible

1赞

谢谢。但 一直是offline状态,感觉tikv的维护好麻烦,关个机维护都不容易(单机的话,怎么kill都没事,集群就不同,管理信息没同步到tidb的pd节点的话,很可能管理上就不正常了)。
另外,请教下:ansible-playbook stop.yml -l 10.10.1.66 是表示仅stop 这台主机的服务么?重新开机后在中控机上ansible-playbook start.yml -l 10.10.1.66 能恢复正常状态么?谢谢。

首先建议你升级到4.0以上版本,用tiup接管集群运维会方便很多。

-l 参数就是只对指定的节点操作

1赞

好的。多谢。

非常感谢。不过我还是有以下几点想打扰下你:
1)升级到4.0以上时,数据不会有什么兼容问题吧?tiup来停服务应该就方便多了吧?我先测试下。
2)pd-ctl -u “http://10.10.2.63:2379” -d store delete 5 和pd-ctl -d -u “http://10.10.2.63:2379” -d store delete 5 (-u前面多了-d,说是动态删除的意思) 的区别在哪里呢?
3)如果某节点一直不能成为Tombstone状态(我在数据量很小的v3.0.9测试环境都是这样,因为生产仍是v3.0.9),能不能在pd将这个故障节点的相关信息清理掉?
如果实在不同,我就只好先升级看看了,多谢。

数据不会有问题,升级参考SOP系列https://asktug.com/t/topic/37283

1赞

好的。非常感谢。

2)从文档来看,-d是进入单命令行模式,并没有看到动态删除的说明,你的参考资料是否能发一下
3)offline状态表示tikv正在转移数据,如果一直卡在这个状态可以检查下日志文件,可能是其他tikv磁盘空间不足导致卡住,如果是用tiup的话可以用–force参数强制缩掉,tidb-ansible不太熟不清楚是否能这样玩。不建议通过pd改元数据,容易玩崩。

1赞

1)第一点是网上找到的资料,应该不准确;
2)我的测试环境资料很小(一个库一个表,用for循环才写入几千条记录,边写入边操作,以模拟线上环境),是刚搭建好的,想先模拟缩扩容的方式,下线故障tikv,不料store delete 后,一直是offline状态(近2个小时了),没有变为Tombstone状态(此时我直接ansible-playbook stop.yml -l ‘tikv-ip’,再按官网流程最后ansible-playbook start.yml -l ‘tikv ip’)也是不行的,应该此时pd的管理数据不一致了,所以现在那个故障tikv主机暂时不敢下线维护~~,到时上线后数据异常或不能up就麻烦了~~~
综上所述,我先做下从v3.0.9到4.0以上版本的升级测试(根据你的经验,最多能升到什么版本呢,建议下啦)吧,有问题再向你请教,多谢。

如果AP类需求不大的话,可以考虑升级到4.0比较新的版本

嗯,主要是用来大数据分析

5以上版本可以考虑使用5.1.1

v3.0.9,可以直接升到v5.1.1版本不?
另外,v5.1.1是稳定版本吧,上线多久呢?

先不打扰你了,晚安。非常感谢。

3到5不能直接升级,要从3到4到5这样。5.1.1的发版信息可以看下官网版本release页面。

我现在还睡不了,因为,还在加班。。。:rofl::rofl:

1赞

:+1:辛苦啦。3个tikv的集群,如果其中一个tikv直接关机(或如机器有故障宕机了),会有什么情况?机器重启开机后,一般要做哪些操作?pd节点还能管理到吗?
2)另外,ansible-playbook stop.yml -l 节点ip,这个命令不仅仅是停止服务吧?如果仅仅是停止服务,我直接在中控机上对有故障的tikv执行这条命令,然后关机维护完成后,执行ansible-playbook start.yml -l tikv节点ip ,tikv能正常使用么?tikv要想变为tombstone状态好麻烦。

1、3tikv关机一个没啥影响,数据都还在服务可用,集群元信息也在,可以参考【SOP 系列 18】TiUP 环境恢复 TiKV 副本。如果是tiup管理的集群,tikv重启后会自动恢复(disconnect变成up),ansible不太清楚,应该也差不多吧。
2、tidb-ansible没有深入研究,你可以看下yml文件和关联的shell脚本,里面做了啥应该容易看出来https://github.com/pingcap/tidb-ansible

1赞

处理好了。我看了下脚本,就是stop tikv的服务。但换了内存后,我发现一个问题,就是用region check miss-peer 查看时,有些region缺少副本数,但存储肯定是够的,另外我也没有使用存储的别名(搭建时只是指定了存储的ip),能不能为这些缺少replica的region手工指定store (如store 5是存在的)? 多谢。

补充下:
1)store为5的主机内存换好后,tikv的状态是up的。region check pending-peer检查时一些有pending的region都是在store 5上,状态为"is_learner": true,如下:
“pending_peers”: [
{
“id”: 526256,
“store_id”: 5,
“is_learner”: true
}
2)维护过的store 5 , region_count比维护前要少了几千个。
非常感谢你的解答。