llplmlyd
(Llplmlyd)
21
走tikv没有问题 集群能修复正常状态即可:pleading_face:
变成offilne状态1个多小时了 数据量200G/节点
节点从故障之后就一直是处于down的状态 ,刚发现官方文档说 如果在节点停止前需要先清楚同步信息 刚刚才把这个tiflash的同步规则清除
curl http://10.64.148.134:2379/pd/api/v1/config/rules/group/tiflash
curl -v -X DELETE http://10.64.148.134:2379/pd/api/v1/config/rule/tiflash/table-280-r
curl -v -X DELETE http://10.64.148.134:2379/pd/api/v1/config/rule/tiflash/table-408-r
curl -v -X DELETE http://10.64.148.134:2379/pd/api/v1/config/rule/tiflash/table-409-r
清除同步规则后
直接用pd-ctl移除是用这个吗
curl -X POST ‘
http://10.64.148.134:2379/pd/api/v1/store/50/state?state=Tombstone’
我用一个节点测试了 显示为Tombstone的状态了,全部改成tombstone之后是不是 edit-config删除tiflash的信息就好。。
不会出现新的bug 了吧
后续2021年3月3日异常tiflash结束pending状态成为tombstone节点
llplmlyd
(Llplmlyd)
23
根据官方文档操作 当节点处于下线状态之后,无论删除与否,均无法通过tiup edit-config移除相关tiflash的信息
异常信息如
最后是删除数据目录之后发现节点处于up状态进一步使用scale-in后变为tombstone,使用tiup cluster prune 清除节点相关信息的
不懂就问
(zhouyueyue)
24
最开始看状态都是 down ,这里提到的节点处于 UP 状态是什么情况?另外现在缩容 、扩容以及升级的操作都做完了吗?
llplmlyd
(Llplmlyd)
25
在我之前的display状态中有展示tiflash属于down的状态
之后分别通过scale-in、store-delete 还有cul -x delete 三种方法对其进行缩容 强制删除 强制下线的操作
当删除了同步规则之后,三个节点均变为tombstone,
但只有第一种方法scale-in的节点处于正常可以prune的状态,其他的两个节点均无法清除配置信息。
scael-in节点进行prune之后数据文件能够自行清空
store delete节点 尝试再次使用scale-in,返回失败,观察对应节店tiflash进程同步被拉起,一段时间后停止,手动删除异常节点的data目录(存在部分文件无法删除),发现进程又再次拉起,此时使用scale-in成功,过一段时间降为tombstone后可prune
另外一个异常节点同步操作,恢复正常,缩容成功。
最后对节点进行tiup cluster upgrade 顺利 扩容顺利 ,清空异常表tidb-lightning导入数据顺利暂时无其他异常
不懂就问
(zhouyueyue)
26
好的 ,导完数在测试下 TiFlash 查询是否正常。
system
(system)
关闭
29
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。