现在是我看到有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 分钟后被自动关闭。不再允许新回复。