alibaba
Nacos集群不同节点之间数据不一致问题
Describe the bug step1：在某次版本升级过程中，下午4点50多的时候，在Nacos集群中，通过web端，登录Nacos，更改了Redis的相关配置，由Redis的单节点配置修改为Redis哨兵模式，并且确认，redis配置已经修改成功 step2：等到晚上7点多的时候，在升级应用的过程中，发现应用节点无法启动，日志报错为连接Redis失败；此时去到Nacos中，确认Redis配置正确； step3：应用经过自动重启后，启动成功；（有的应用重启一次就能启动成功，有的应用需要重启2~3次才能成功） step4：经过仔细排查应用日志，发现应用在首次启动时，无法正常启动的日志，拉取的配置，依旧是Redis单节点的配置（原来的配置）；启动成功的日志，拉取到的配置是Redis哨兵配置（正常配置） step5：对启动成功的应用，再次重启，还是需要多次重启，才能启动成功 step6：此时，再次去到Nacos端，登录Nacos后发现，Redis的配置正常的；此时又重新点击了两次发布的按钮 step7：再次重启应用，可以一次启动成功
此时，大概定位到Nacos节点配置同步问题，于是，去到Nacos端，查看Nacos日志，在不同的Nacos节点，发现了不同的日志：
2024-07-30 16:57:30,669 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false
2024-07-30 16:57:30,685 WARN [dump-ignore] ignore to save cache file. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, md5=cf0244c69e8494e0399d2597cd4e63a5, lastModifiedOld=1722317072218, lastModifiedNew=1722329850583
2024-07-30 16:57:30,671 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false
2024-07-30 16:58:15,659 INFO [dump-task] add task. groupKey=db-RedisCache.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=db-RedisCache.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false+null
2024-07-30 16:59:21,238 INFO [dump-task] add task. groupKey=tcp-xy-adapter.yaml+DEFAULT_GROUP+2a45eb77-cd39-41de-8d23-52ad3c81bacc, taskKey=tcp-xy-adapter.yaml+DEFAULT_GROUP+2a45eb77-cd39-41de-8d23-52ad3c81bacc+false
2024-07-30 17:00:04,355 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+36be8d74-5227-4ba5-9695-86a93faa1afb, taskKey=redis.properties+DEFAULT_GROUP+36be8d74-5227-4ba5-9695-86a93faa1afb+false
2024-07-30 17:27:24,965 WARN [dump-ignore] ignore to save cache file. groupKey=fp-gateway-pro.yml+DEFAULT_GROUP+3bd32204-b63d-49d9-bc6a-e00eb822ed12, md5=46d4123f77da100a199ae28480ed1d81, lastModifiedOld=1715069871652, lastModifiedNew=1715069872000
Desktop (please complete the following information):
- Version v2.2.3
看起来是时区或者时钟的问题， 不同的节点时区或时钟好像不同，导致某个节点写入数据库的时间比其他节点的旧，其他节点认为这个配置是旧配置，于是就忽略了。
可以看下多个nacos节点是不是时区或者时间不一致。
您好，根据您的反馈，然后检查了Nacos的各个节点的时间和时区，以及Nacos使用的Mysql的时间，都是一致的； 另外，补充一下： 1.Nacos中储存到Mysql的配置，应该是正常的，推测是不是Nacos中有相关的缓存的文件的更新问题 2.Nacos中，是否存在对账的机制，或者说，是否会定时的刷新Nacos中的缓存文件？如果有，如何开启
Nacos中，是否存在对账的机制，或者说，是否会定时的刷新Nacos中的缓存文件？如果有，如何开启。
默认开启，每6h和数据库中的数据进行全量对账。
这个问题之前有遇到的情况，基本都是和时区时钟有关系，时区的不同包括了在jdbcurl上配置的不同等。
建议出现问题时，可以在jdbcurl上强制指定时区。
您好：关于您反馈的6h全量对账机制，我这边测试了一下，发现异常数据并没有做改观，具体验证步骤如下： step1：通过web端，登录Nacos后，新增一个变量nacos.test:test001；然后通过应用拉取该变量，可以正常拉取到test001； step2：在数据库中（Mysql）中，找到新增的变量，修改该变量的值为test002，此时，通过web端访问，查看到的变量值，为修改后的值test002；重启应用后，拉取到的变量值依旧是test001; step3：等过6个小时，重启应用后，再次通过应用拉取变量的值，依旧是test001，并不是期望的test002 所以，才会有上一条问题中的对账机制，是否需要手动的开启 麻烦帮忙确认一下，此验证步骤是否正确
Describe the bug step1：在某次版本升级过程中，下午4点50多的时候，在Nacos集群中，通过web端，登录Nacos，更改了Redis的相关配置，由Redis的单节点配置修改为Redis哨兵模式，并且确认，redis配置已经修改成功 step2：等到晚上7点多的时候，在升级应用的过程中，发现应用节点无法启动，日志报错为连接Redis失败；此时去到Nacos中，确认Redis配置正确； step3：应用经过自动重启后，启动成功；（有的应用重启一次就能启动成功，有的应用需要重启2~3次才能成功） step4：经过仔细排查应用日志，发现应用在首次启动时，无法正常启动的日志，拉取的配置，依旧是Redis单节点的配置（原来的配置）；启动成功的日志，拉取到的配置是Redis哨兵配置（正常配置） step5：对启动成功的应用，再次重启，还是需要多次重启，才能启动成功 step6：此时，再次去到Nacos端，登录Nacos后发现，Redis的配置正常的；此时又重新点击了两次发布的按钮 step7：再次重启应用，可以一次启动成功
此时，大概定位到Nacos节点配置同步问题，于是，去到Nacos端，查看Nacos日志，在不同的Nacos节点，发现了不同的日志：
2024-07-30 16:57:30,669 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false 2024-07-30 16:57:30,685 WARN [dump-ignore] ignore to save cache file. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, md5=cf0244c69e8494e0399d2597cd4e63a5, lastModifiedOld=1722317072218, lastModifiedNew=17223298505832024-07-30 16:57:30,671 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false 2024-07-30 16:58:15,659 INFO [dump-task] add task. groupKey=db-RedisCache.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=db-RedisCache.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false+null 2024-07-30 16:59:21,238 INFO [dump-task] add task. groupKey=tcp-xy-adapter.yaml+DEFAULT_GROUP+2a45eb77-cd39-41de-8d23-52ad3c81bacc, taskKey=tcp-xy-adapter.yaml+DEFAULT_GROUP+2a45eb77-cd39-41de-8d23-52ad3c81bacc+false 2024-07-30 17:00:04,355 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+36be8d74-5227-4ba5-9695-86a93faa1afb, taskKey=redis.properties+DEFAULT_GROUP+36be8d74-5227-4ba5-9695-86a93faa1afb+false 2024-07-30 17:27:24,965 WARN [dump-ignore] ignore to save cache file. groupKey=fp-gateway-pro.yml+DEFAULT_GROUP+3bd32204-b63d-49d9-bc6a-e00eb822ed12, md5=46d4123f77da100a199ae28480ed1d81, lastModifiedOld=1715069871652, lastModifiedNew=1715069872000Desktop (please complete the following information):
- Version v2.2.3
老哥我个人拙见: 我看了下这个版本的同步配置忽略配置逻辑, 主要是要新内容和缓存内容MD5一致的情况, 且同步配置时是从数据库拉取的最新配置内容比对, 当时是确认了集群每个节点控制台的配置一致嘛？对账这个使用dump-all关键字搜索一下呢, 对于控制台触发的变更还可以看一下config-trace.log记录？
Nacos中，是否存在对账的机制，或者说，是否会定时的刷新Nacos中的缓存文件？如果有，如何开启。
默认开启，每6h和数据库中的数据进行全量对账。
这个问题之前有遇到的情况，基本都是和时区时钟有关系，时区的不同包括了在jdbcurl上配置的不同等。
建议出现问题时，可以在jdbcurl上强制指定时区。
您好，我们通过在jdbcurl上添加了相关时区配置（serverTimezone=Asia/Shanghai），现在会触发每6h和数据库中的数据进行全量对账的机制了，对于这个6h的时间，是否可以修改，比如，是否可以修改成1h，相关参数是哪一个
全量对账目前是6h无法修改，这个主要作用是兜底的操作，时间太长或太短可能都不合适， 6h是一个阿里巴巴大规模使用过程中调整的一个比较好的一个经验值。
你可以尝试升级到2.3.0+，新增了一个增量对账的机制，每30s执行一次， 可能能解决你现在遇到的问题。
不过最关键的，还是找到为什么会不一致， 因为我这边很多环境都没有办法复现这个问题，正常的变更配置，在时区，始终都没有问题的情况下， 配置写入数据库后会触发全集群的dump操作，该配置会在1s左右（正常情况下时间更短）被dump到磁盘缓存中。
No more response from author for a long time, and this problem community can't reproduce.
这个问题有解吗？我这里也遇到了。三个节点的nacos集群，例如修改data_id 为xxx.yml，分别在三个节点的web端查看配置均生效。用nacos API读取发现某一个节点读到的还是历史配置，每次必须重新提交才能生效。
Describe the bug step1：在某次版本升级过程中，下午4点50多的时候，在Nacos集群中，通过web端，登录Nacos，更改了Redis的相关配置，由Redis的单节点配置修改为Redis哨兵模式，并且确认，redis配置已经修改成功 step2：等到晚上7点多的时候，在升级应用的过程中，发现应用节点无法启动，日志报错为连接Redis失败；此时去到Nacos中，确认Redis配置正确； step3：应用经过自动重启后，启动成功；（有的应用重启一次就能启动成功，有的应用需要重启2~3次才能成功） step4：经过仔细排查应用日志，发现应用在首次启动时，无法正常启动的日志，拉取的配置，依旧是Redis单节点的配置（原来的配置）；启动成功的日志，拉取到的配置是Redis哨兵配置（正常配置） step5：对启动成功的应用，再次重启，还是需要多次重启，才能启动成功 step6：此时，再次去到Nacos端，登录Nacos后发现，Redis的配置正常的；此时又重新点击了两次发布的按钮 step7：再次重启应用，可以一次启动成功
此时，大概定位到Nacos节点配置同步问题，于是，去到Nacos端，查看Nacos日志，在不同的Nacos节点，发现了不同的日志：
2024-07-30 16:57:30,669 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false 2024-07-30 16:57:30,685 WARN [dump-ignore] ignore to save cache file. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, md5=cf0244c69e8494e0399d2597cd4e63a5, lastModifiedOld=1722317072218, lastModifiedNew=17223298505832024-07-30 16:57:30,671 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=redis.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false 2024-07-30 16:58:15,659 INFO [dump-task] add task. groupKey=db-RedisCache.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3, taskKey=db-RedisCache.properties+DEFAULT_GROUP+391d86d8-dbdf-4580-aa63-af06225007c3+false+null 2024-07-30 16:59:21,238 INFO [dump-task] add task. groupKey=tcp-xy-adapter.yaml+DEFAULT_GROUP+2a45eb77-cd39-41de-8d23-52ad3c81bacc, taskKey=tcp-xy-adapter.yaml+DEFAULT_GROUP+2a45eb77-cd39-41de-8d23-52ad3c81bacc+false 2024-07-30 17:00:04,355 INFO [dump-task] add task. groupKey=redis.properties+DEFAULT_GROUP+36be8d74-5227-4ba5-9695-86a93faa1afb, taskKey=redis.properties+DEFAULT_GROUP+36be8d74-5227-4ba5-9695-86a93faa1afb+false 2024-07-30 17:27:24,965 WARN [dump-ignore] ignore to save cache file. groupKey=fp-gateway-pro.yml+DEFAULT_GROUP+3bd32204-b63d-49d9-bc6a-e00eb822ed12, md5=46d4123f77da100a199ae28480ed1d81, lastModifiedOld=1715069871652, lastModifiedNew=1715069872000Desktop (please complete the following information):
- Version v2.2.3
老哥你这里nacos后端数据源使用的是多实例做读写分离了吗，根据上边大哥分析逻辑，会不会是多数据源同步延时导致没有读取到最新数据
这个问题有解吗？我这里也遇到了。三个节点的nacos集群，例如修改data_id 为xxx.yml，分别在三个节点的web端查看配置均生效。用nacos API读取发现某一个节点读到的还是历史配置，每次必须重新提交才能生效。
目前我们的做法是这样的：新增了一个环境变量：
- name: MYSQL_SERVICE_DB_PARAM value: "characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useSSL=false&serverTimezone=Asia/Shanghai"
修改完以后，目前没发现再出现这个问题 这个环境变量的使用，登录到容器中，可以看到具体的使用： 具体目录为：/home/nacos/conf/application.properties
在原来默认值的基础上，新增加了&serverTimezone=Asia/Shanghai 注意：原来的环境变量中，是没有MYSQL_SERVICE_DB_PARAM这个环境变量的，需要自己手动添加