Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.4.2使用helm部署集群,动态扩缩容时选主失败:can't do preVote as it is not in conf #214

Open
zcz3313 opened this issue May 9, 2021 · 23 comments
Assignees

Comments

@zcz3313
Copy link

zcz3313 commented May 9, 2021

问题现象:
如题,查看alipay-jcraft.log中的内容如下
image

重现步骤:
1.使用1.4.2的helm包,集群模式,embedded存储模式
2.statefulset的副本数设置为3
3.pod全部启动成功后,登录nacos控制台正常
4.使用kubectl scale sts middleware-nacos-server --replicas=0 缩容并等待所有pod销毁成功
5.再使用上述命令 --replicas=3 扩容并等待所有pod创建成功
6.登录nacos控制台,报502错误,查看选举日志报错

其他信息:
详细的日志信息将以附件形式上传
node0.tar.gz
node1.tar.gz
node2.tar.gz

@zcz3313
Copy link
Author

zcz3313 commented May 9, 2021

经过多次测试,发现,只要让缩容掉多数节点后,再恢复到最初的节点数,重新恢复的节点就会报这个错。
例如,初始3节点:
case 1, --replicas=2然后再--replicas=3,之前关停的node-2再重新启动后能正常加入集群
case 2, --replicas=1然后再--replicas=3,之前关停的node-1和node-2再重新启动后不能正常加入集群,选举日志报错。

@paderlol
Copy link
Collaborator

好的 我们这边先看一下

@paderlol
Copy link
Collaborator

你扩容后每台节点的pod都running了吗?

@paderlol
Copy link
Collaborator

你case2 里面能否通过控制台看到集群节点的状态?看下剩下那台节点状态是否正确,我们现在初步怀疑是当节点一次性缩容超过半数的时候,jraft这个时候还没选出主无法更新自己的conf导致的,但是只要不超过半数就不会有这个问题,比如5台节点可以直接缩容到3台

@paderlol paderlol self-assigned this May 10, 2021
@zcz3313
Copy link
Author

zcz3313 commented May 10, 2021

你case2 里面能否通过控制台看到集群节点的状态?看下剩下那台节点状态是否正确,我们现在初步怀疑是当节点一次性缩容超过半数的时候,jraft这个时候还没选出主无法更新自己的conf导致的,但是只要不超过半数就不会有这个问题,比如5台节点可以直接缩容到3台

好的,我下午再测试一次。另外想再咨询一下,在集群模式下,nacos的副本数为1也不行吗?我自己测试的时候,想着说始终运行在集群模式下,但是仅仅通过副本数来模拟单机部署的效果。但是发现nacos是不可用的。

@paderlol
Copy link
Collaborator

你是说只启动一个节点吗?

@zcz3313
Copy link
Author

zcz3313 commented May 10, 2021

你是说只启动一个节点吗?

是的

@zcz3313
Copy link
Author

zcz3313 commented May 10, 2021

你case2 里面能否通过控制台看到集群节点的状态?看下剩下那台节点状态是否正确,我们现在初步怀疑是当节点一次性缩容超过半数的时候,jraft这个时候还没选出主无法更新自己的conf导致的,但是只要不超过半数就不会有这个问题,比如5台节点可以直接缩容到3台

控制台上显示如图
image
剩余的这个节点的raft日志报错如下
image

@zcz3313
Copy link
Author

zcz3313 commented May 10, 2021

你是说只启动一个节点吗?

刚才在现有环境测试了一下是没问题的,可能是我自己的原因。我再重新清空环境部署一次试试看。

@paderlol
Copy link
Collaborator

你case2 里面能否通过控制台看到集群节点的状态?看下剩下那台节点状态是否正确,我们现在初步怀疑是当节点一次性缩容超过半数的时候,jraft这个时候还没选出主无法更新自己的conf导致的,但是只要不超过半数就不会有这个问题,比如5台节点可以直接缩容到3台

控制台上显示如图
image
剩余的这个节点的raft日志报错如下
image

因为一次性杀了过半节点,这个时候可能新leader没选出来,或者不够半数节点已经无法选出leader了,无法去更改jraft自己的conf,所以出现没办法自愈了,暂时只能一台一台去启停吧,后续会Nacos本身会想办法优化一下这个

@zcz3313
Copy link
Author

zcz3313 commented May 10, 2021

你case2 里面能否通过控制台看到集群节点的状态?看下剩下那台节点状态是否正确,我们现在初步怀疑是当节点一次性缩容超过半数的时候,jraft这个时候还没选出主无法更新自己的conf导致的,但是只要不超过半数就不会有这个问题,比如5台节点可以直接缩容到3台

控制台上显示如图
image
剩余的这个节点的raft日志报错如下
image

因为一次性杀了过半节点,这个时候可能新leader没选出来,或者不够半数节点已经无法选出leader了,无法去更改jraft自己的conf,所以出现没办法自愈了,暂时只能一台一台去启停吧,后续会Nacos本身会想办法优化一下这个

好的,谢谢解答。另外,我测试了两次,关于集群模式下只部署单个节点的场景,两次的表现都是nacos的pod能正常running,控制台能登录,但是服务注册模块的接口报503。
image
image
后端服务在调用注册接口的时候也是报以上的错误。

@kuaile-zc
Copy link
Contributor

您好我遇到了相同的问题,请问这个问题解决了吗?有什么解决方案或者其他问题。

@paderlol
Copy link
Collaborator

paderlol commented Nov 3, 2021

可以尝试用operator

@paderlol
Copy link
Collaborator

paderlol commented Nov 3, 2021

@kuaile-zc
Copy link
Contributor

https://github.com/nacos-group/nacos-k8s/tree/master/operator

这个模式与之前的有什么区别吗,因为K8s这块不是特别熟悉

@kuaile-zc
Copy link
Contributor

@zcz3313 您好我描述一下我的困境,我们使用Heml部署方式,有时会将nacos服务重启,k8s杀一台之后另一台立马就杀掉实际上nacos还没初始化完成。造成的结果是三台pod重新启动之后在nacos UI控制台查看集群状态不正常节点信息不同步。我查看了您的解决过程发现官方给的结果是设置热启动为fasle。
我发现您的问题和我十分类似请问设置完 nacos.naming.data.warmup=false之后就正常了吗?

@paderlol
Copy link
Collaborator

paderlol commented Nov 3, 2021

你可以尝试这个方案,也可以使用operator,这是一种操作k8s的方式,具体使用方式有文档,另外区别就是它启动会监控节点状态

@kuaile-zc
Copy link
Contributor

你可以尝试这个方案,也可以使用operator,这是一种操作k8s的方式,具体使用方式有文档,另外区别就是它启动会监控节点状态

由于我们运维平台是基于helm的底座部署所以迁移一种方式可能代价比较大,我们会尝试研究一下两者的不同。
后续本地测试对比一下使用配置修改的方式。
十分感谢您的回答 @paderlol ..我们测试有结果也会第一时间分享。

@paderlol
Copy link
Collaborator

paderlol commented Nov 3, 2021

这种也可以helm部署

@zcz3313
Copy link
Author

zcz3313 commented Nov 4, 2021

@zcz3313 您好我描述一下我的困境,我们使用Heml部署方式,有时会将nacos服务重启,k8s杀一台之后另一台立马就杀掉实际上nacos还没初始化完成。造成的结果是三台pod重新启动之后在nacos UI控制台查看集群状态不正常节点信息不同步。我查看了您的解决过程发现官方给的结果是设置热启动为fasle。 我发现您的问题和我十分类似请问设置完 nacos.naming.data.warmup=false之后就正常了吗?

这个参数能解决我提出的“使用集群模式但是副本数设置为1”的问题,无法解决“多数节点down掉后,集群无法通过节点自我重启后恢复自愈”的问题,依旧需要手动删除协议持久化目录,人工介入。
详情参考这里

另一个方案是把数据同步下移到存储层,将nacos当做无状态的各个单机节点,外接高可用数据库(mysql集群化),此时的nacos各个节点的工作模式是standalone,各节点不相互通信。此方案应该也可以,但是我没有试过。鉴于我们公司的实际情况,我还是选择了nacos的内置存储模式。

BTW,我查阅了一些资料,从raft协议官网上没有找到相关说明,即“过半数节点短时间内宕机后再重启,整个集群能否重新选出领导人”,但我推测应该是可以的。nacos底层raft协议使用的是jraft实现,可以去jraft那边提一个issue试试。我个人鉴于时间问题没有太多精力深入追踪,如果你有更多发现欢迎随时探讨。

@kuaile-zc
Copy link
Contributor

@zcz3313 您好我描述一下我的困境,我们使用Heml部署方式,有时会将nacos服务重启,k8s杀一台之后另一台立马就杀掉实际上nacos还没初始化完成。造成的结果是三台pod重新启动之后在nacos UI控制台查看集群状态不正常节点信息不同步。我查看了您的解决过程发现官方给的结果是设置热启动为fasle。 我发现您的问题和我十分类似请问设置完 nacos.naming.data.warmup=false之后就正常了吗?

这个参数能解决我提出的“使用集群模式但是副本数设置为1”的问题,无法解决“多数节点down掉后,集群无法通过节点自我重启后恢复自愈”的问题,依旧需要手动删除协议持久化目录,人工介入。 详情参考这里

另一个方案是把数据同步下移到存储层,将nacos当做无状态的各个单机节点,外接高可用数据库(mysql集群化),此时的nacos各个节点的工作模式是standalone,各节点不相互通信。此方案应该也可以,但是我没有试过。鉴于我们公司的实际情况,我还是选择了nacos的内置存储模式。

BTW,我查阅了一些资料,从raft协议官网上没有找到相关说明,即“过半数节点短时间内宕机后再重启,整个集群能否重新选出领导人”,但我推测应该是可以的。nacos底层raft协议使用的是jraft实现,可以去jraft那边提一个issue试试。我个人鉴于时间问题没有太多精力深入追踪,如果你有更多发现欢迎随时探讨。

十分感谢你的解答。我会做出验证,并且持续跟踪问题如果有进展我会反馈到问题上面
Thank you very much for your answer. I'm going to do validation and I'm going to keep tracking the issues and I'm going to feed back to the issues if there's any progress

@zcz3313
Copy link
Author

zcz3313 commented Nov 5, 2021

十分感谢你的解答。我会做出验证,并且持续跟踪问题如果有进展我会反馈到问题上面 Thank you very much for your answer. I'm going to do validation and I'm going to keep tracking the issues and I'm going to feed back to the issues if there's any progress

节点感知我是使用nacos-peer-finder插件,你可以换成写死固定节点的方式来对比测试一下。

@qhyjoe
Copy link

qhyjoe commented Oct 1, 2022

可以尝试用operator

目前只能使用operator解决吗

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants