We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
目前看客户端同一个dataId和group,推送相同的配置内容也会写到数据库,同时产生一个新的历史版本写入到his_config_info。 是否有可能支持在application.properties中配置,如果推送的配置内容相同,就不写入到数据库,目前我们的数据库磁盘规格较小,目的是为了缓解数据库磁盘压力。 还是说这种特性更倾向于用户自己的业务代码来控制呢?如果是业务代码控制,是不是只能先查询服务端最新配置来对比,感觉会有点麻烦
The text was updated successfully, but these errors were encountered:
我理解应该是由业务代码来控制比较好,因为配置内容对Nacos来说只黑盒,为保证数据的一致性, Nacos仅计算md5值并写入数据库,md5值只作为数据一致性的判断,而不作为重复内容的判断。
配置是否真的需要写入, 需要更新,是否重复主要还是业务测来判断比较合理。
Sorry, something went wrong.
1.这种情况由用户自行控制比较好,假设要调整,那么nacos服务端该如何返回比较好呢?假设返回报错,对客户端程序侧不友好,正常是需要幂等返回的,如果返回成功,服务端没有任何记录,对问题排查也有影响。
2.配置中心本身适合的场景是写少读少的场景,关注的是配置推送的实时性,写入过多的场景本身可能就是一种误用
3.针对数据库磁盘压力问题,可以调整参数降低配置定清理任务的保留时长,也可以在数据库侧写定时任务,将不需要的历史记录清理
我们目前也遇到了这个问题,主要是在Dubbo的元数据上报上。 有非常大量的、完全相同的历史记录被持久化。
目前我们修改了业务逻辑,降低客户端的写入频率来暂时避免此问题,看其他用户也有类似问题,通过issue#12834继续跟踪
No branches or pull requests
目前看客户端同一个dataId和group,推送相同的配置内容也会写到数据库,同时产生一个新的历史版本写入到his_config_info。
是否有可能支持在application.properties中配置,如果推送的配置内容相同,就不写入到数据库,目前我们的数据库磁盘规格较小,目的是为了缓解数据库磁盘压力。
还是说这种特性更倾向于用户自己的业务代码来控制呢?如果是业务代码控制,是不是只能先查询服务端最新配置来对比,感觉会有点麻烦
The text was updated successfully, but these errors were encountered: