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
前情 #12769
dubbo3有非常多的元数据,和定时update元数据的机制。外加开发测试环境有较高频率地节点重启发生,导致了历史记录的量级非常大。(在不到30天内积累了大约2000条元数据和90万条历史)。
此时以10分钟为周期,清理histroy的sql会阻塞+超时。使用id或者nid的语句都会超时(即使最终一条都不会删除,也要执行很久。本地datagrip跑大致要5~8秒,服务器上挂盘的要更慢些)。
我们需要一些更贴近“服务器负载”、“服务器容量”的概念,作为单纯的“保留30天”这样的业务概念的补充。例如“保留30天,且至多保存1000条”。 或者为dubbo元数据的场景制定一些特殊方案,例如专门为一些命名空间关闭历史记录功能。或者一些特殊的接口参数,允许dubbo框架上报元数据时不记录历史版本。
另外这些场景下,当每半小时触发快照生成的时候,也是灾难性的。 不确定我理解是否准确,但是观察到每次快照生成都会导致丢失leader并重新选主,同时触发大量timeout的报错。 快照生成或者sql执行超时,会影响集群间心跳吗?
The text was updated successfully, but these errors were encountered:
这里有两个方面:
@shiyiyue1102 可以讨论一下。
Sorry, something went wrong.
No branches or pull requests
前情 #12769
dubbo3有非常多的元数据,和定时update元数据的机制。外加开发测试环境有较高频率地节点重启发生,导致了历史记录的量级非常大。(在不到30天内积累了大约2000条元数据和90万条历史)。
此时以10分钟为周期,清理histroy的sql会阻塞+超时。使用id或者nid的语句都会超时(即使最终一条都不会删除,也要执行很久。本地datagrip跑大致要5~8秒,服务器上挂盘的要更慢些)。
我们需要一些更贴近“服务器负载”、“服务器容量”的概念,作为单纯的“保留30天”这样的业务概念的补充。例如“保留30天,且至多保存1000条”。
或者为dubbo元数据的场景制定一些特殊方案,例如专门为一些命名空间关闭历史记录功能。或者一些特殊的接口参数,允许dubbo框架上报元数据时不记录历史版本。
另外这些场景下,当每半小时触发快照生成的时候,也是灾难性的。
不确定我理解是否准确,但是观察到每次快照生成都会导致丢失leader并重新选主,同时触发大量timeout的报错。
快照生成或者sql执行超时,会影响集群间心跳吗?
The text was updated successfully, but these errors were encountered: