[alibaba/nacos]Nacos2.0.3 3节点集群，重启后数据节点不一致

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

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

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

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, 这样对集群数据一致性有没有影响？

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

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.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协议？ 不胜感激!

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

根据你的以上3点回复，有以下问题：

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

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

若"问题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" ，是不是这个原因导致的？

感谢!

1. 是
2. 是
3. 可以看upgraded是否都是true， 如果都是true就没问题，verify client xxx:36023#true failed, sync new client 有可能发生在某个服务刚注册，还没来及的同步（有延迟队列），但是校验任务先触发了的情况，需要配合naming-server.log一起看。 如果xxx:36023在naming-server.log一直变化， 那经常有verify client xxx:36023#true failed其实就是正常的。

看端口应该是udp自动申请的端口吧，应该是订阅者的请求，每隔一段时间就会来轮询查询一下， 查询的时候就会订阅一下，这个时候就是connect， 之后不查询了就会disconnect。 建议升级到2.x的客户端，长链接的话会稳定很多。 和数据不一致没关系。