现在是我看到有4000的端口,但是通过mysql 的客户端也是无法连接进去的,所以我也没办法知道里面的表以及数据,现在的服务是没办法正常的读写的!所以应该也是没办法使用dumpling进行备份的
1 个赞
那先恢复集群的状态吧,你是3.x 的版本
可以考虑用ansible 在扩容一下tikv节点,满足之前配置的5个节点的情况,在看看
如果恢复不了集群状态,就没办法备份数据了
那没辙了,如果3.0.4将宕机的节点换成3.0.11版本,和之前的整合一起应该会出现版本不兼容的问题吧?
2 个赞
宕机的节点,需要正常的下线,不然会一直挂在集群中,为 offline 的状态
因为不是 5 副本,还不知道宕掉的2个节点中的数据,是否有其他的副本在另外的节点上,这个无法确认
现在要考虑把 宕掉的节点先启动起来,然后考虑滚动升级会更安全
1 个赞
现在启动不了的TiKV就是3.0.11版本修复的raftstore所提及到的那个BUG,里面有同样的报错!这的估计没得救了,发现有bug的那会集群不升级非要等的集群挂了才想办法修复
1 个赞
老师,还有个问题想了解一下,如果我进行集群的升级从3.0升级到4.0在升级到最新,升级完之后集群能都访问么?之前的这个数据有没有保证能够不丢失?
1 个赞
5 节点,一般会配置为 5 副本,这样的话,最大可以容忍 2个节点坏掉,集群还可用
3 节点,一般会配置为 3 副本,这样最大容忍 1个 节点坏掉,集群可用
这种情况,要优先扩容节点,满足集群的基准配置,这样后续的调度才能生效,也就是说这样才能保证数据安全;
升级一般也是 集群正常 的情况下,才能做滚动式升级
我这样描述,可以理解么?
2 个赞
好的!感谢老师的回答 明白了
1 个赞
我也是查到只剩下4.0.0的了 好的谢谢了
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。