nacos Nacos2.0.3 3节点集群,重启后数据节点不一致

kx1ctssn  于 2022-10-21  发布在  Nacos
关注(0)|答案(8)|浏览(1852)

部署环境:
我在3台centos7.6 上部署了3个Nacos2.0.3 节点,组成了一个3节点集群,通过控制台 "集群管理" ==> "节点列表" 3个节点都是UP状态,截图如下

出现的问题:
在节点重启后,3个节点的服务注册信息都不全了<共有4个服务,每个服务双副本运行,部分节点注册了3个,部分节点注册了1个服务>,通过Nacos web控制台的"服务管理" ==> "服务列表" 中查看: Leader节点 和其中一个从节点 只看到注册了3个服务, 另一个从节点只看到一个服务注册上来了, 通过这种现象看,集群显然是没有数据同步了
Leader节点能看到 3个服务<少1个>:

其中一个非Leader节点只能看到1个服务<少3个>:

nacos/v1/ns/upgrade/ops/metrics 接口信息:
查看nacos/v1/ns/upgrade/ops/metrics 接口信息,发现Leader 和其中一个Naocs节点不一样,另一个Naocs节点和Leader是一样的
Leader节点:

另一个和Leader不一样的节点:

集群节点源数据<从控制台"集群管理" ==> "节点列表" ==> “节点元数据” 中拷贝下来的>:
从Leader 节点控制台获取,并对比 每个节点的 "节点元数据":

从其中一个非Leader 节点控制台获取,并对比 每个节点的 "节点元数据":

日志信息: naming-server.log
通过 nacos/v1/ns/upgrade/ops/metrics接口查看,只有 upgraded = false 的节点日志才会打印 "INFO upgrade check result false"

通过以上信息,能看出每个Naocs节点他注册上来的服务数量不全<服务共有4个,注册上来的要么只有3个,要么只有1个>? 集群节点数据不一致的原因吗? 非常感谢

fae0ux8s

fae0ux8s2#

可能是发生了服务降级,应该是发生了服务降级,逐个重启节点应该可以恢复,注意观察日志是否重启成功后再去启动下一个节点
恢复后要关闭双写,不然部署过程中都可能出现

rkue9o1l

rkue9o1l3#

Reference in new issue

重启过,服务还是注册不上来, 不过3个集群中只有一个节点的 data/upgrade.state 值为True, 其余2个节点(包含了Leader节点)的值的 data/upgrade.state为false,由此有2个小问题:

问题1: 这个字段的意思是不是 表示nacos-server服务端是运行在那个版本模式下的

值为true的节点使用的是nacos2.X的功能;
值为false的节点就是就是使用的nacos1.x模式运行(虽然nacos部署的版本是2.0.3版本)?

问题2:我现在这个集群数据不同步的原因是不是 因为集群节点的data/upgrade.state 的不一样导致的?

我的集群data/upgrade.state 值为True的节点naming-distro.log日志如下:
日志关键字: client xxx:port#true is invalid, get new client from xxx

我的集群data/upgrade.state 值为false 的节点naming-distro.log日志如下:
日志关键字: verify client ip:port#true failed, sync new client

zhte4eai

zhte4eai4#

Reference in new issue

Reference in new issue

https://nacos.io/zh-cn/docs/2.0.0-upgrading.html

当集群所有节点管不双写后,并且每个节点的 data/upgrade.state 值为true时, 所有节点的naming-distro.log日志都 提示:Target xxx:8848 verify client xxx:36023#true failed, sync new client, 这样对集群数据一致性有没有影响?

x7yiwoj4

x7yiwoj45#

1.正常情况下2.x的服务端部署后upgrade.state应该是true的,表示所有集群都是2.x模式运行,出现非true的可能是因为降级了
2.关闭双写可以强制服务端升级到2.x
3.报途中的verify client 失败的错说明distro同步失败了,看一下打印出来的ip对应的节点是不是还是处于降级状态
4.查看更多naming相关的日志看是否有更多有用的信息

kxxlusnw

kxxlusnw6#

1、问题1

根据你的第2点回复"2.关闭双写可以强制服务端升级到2.x"得出,我可不可以得出这样的结论: 由于 我已经将所有的Nacos集群节点的双写全关闭了(且所有集群节点的upgrade.state的值都为true),是不是也就意味着我现在的Nacos集群节点就已经强制升级到2.x了 ?

2、问题2

根据你的第3点回复 "3.报途中的verify client 失败的错说明distro同步失败了,看一下打印出来的ip对应的节点是不是还是处于降级状态" 你这里的的"节点"是指nacos服务端? 还是nacos-client客户端<注册到注册中心的服务>?
若是指nacos服务端,那么有什么样的日志信息 来确认他是否处于降级状态?
若是值nacos-client客户端<注册到注册中心的服务>,同样的有什么样的日志信息 来确认他是否处于降级状态?

3、问题3

3.1 若nacos集群在2.x模式下运行<集群所有节点都升级到2.x>, nacos-client-1.4 向nacos-server注册时采用的是grpc协议,还是http协议?
3.2 nacos集群部分节点的upgrade.state的值都为false, 那么 nacos-client-1.4 向nacos-server注册时采用的是grpc协议,还是http协议?
不胜感激!

dnph8jn4

dnph8jn47#

  1. 是,文档有描述
  2. verify 失败是验证失败, 说明目标端的这份数据不存在或内容不正确,然后重新触发同步。
  3. 都是http,1.X客户端没有grpc能力,2.x服务端兼容来自客户端的http请求,1.x模式和2.x模式区别在于处理http请求后,存储在服务端内的数据结构有所不同,接口是一致的。
jw5wzhpr

jw5wzhpr8#

  1. 是,文档有描述
  2. verify 失败是验证失败, 说明目标端的这份数据不存在或内容不正确,然后重新触发同步。
  3. 都是http,1.X客户端没有grpc能力,2.x服务端兼容来自客户端的http请求,1.x模式和2.x模式区别在于处理http请求后,存储在服务端内的数据结构有所不同,接口是一致的。

根据你的以上3点回复,有以下问题:

问题1:

我现在可以确认的是我目前的Nacos集群运行在2.x模式的, 那么新注册服务存储在服务端的数据结构是不是就是2.x模式的数据结构了?

问题2:serviceCountV1 、serviceCountV2表示的含义

通过 nacos/v1/ns/upgrade/ops/metrics 返回的数据来看,serviceCountV1 是不是表示为nacos-client-1.4客户端注册注册中心后,在服务端存储的数据结构为1.x模式下的数据结构的客户端服务数?

问题3:

若"问题1",得到的回复是肯定的,即:新注册到集群的服务存储在服务端的数据结构是2.x模式下的数据结构,那么若集群的其他节点<A节点>存储的有1.x模式的数据结构<在没有升级到2.x模式时,有服务已经注册到集群>,而另一个集群节点<B节点>没有存储1.x模式的数据结构<因为从serviceCountV1 的值为0,得出的结论>,那么在B节点从A节点同步注册的示例数量时,由于现在集群已经运行为2.x模式,B节点又没有存储1.x模式的数据结构,所以B节点在验证通过过来的数据时,发现数据格式识别不了,内容不正确,B节点naming-distro.log日志中才会持续打印"verify client xxx:36023#true failed, sync new client" ,是不是这个原因导致的?

感谢!

相关问题