backupfull.rar (1.6 MB) store信息 (9.7 KB)
问题如题,store信息和备份日志以上传,根据我自己看154节点的leader_size异常的大,是不是这个原因导致的,为什么会出现这种情况,有什么解决办法吗?
稍等，我们确认下是leader count 还是leader size 决定的，稍后答复
备份是备份的 leader 数据，所以某个 store 上备份下来的数据过大，是因为 leader 数据分布不均匀导致，能确认下
- 备份前发生了什么操作？
- 备份前的监控看看集群是不是就是已经 leader 不均匀了？
再确认下这个集群的数据，是正常写入的还是通过其他工具导入的呢？
这个集群数据是正常写入的,目前4.0系统是从以前3.+版本转到tiup然后升级的
另外直接登录154这台服务查看磁盘占用空间只有不到200G
- 可以反馈下 grafana 的 over-view, pd, tikv 信息吗？ 备份前到现在的
(1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl
(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。
(3)、使用这个 full-page-screen-capture 插件进行截屏保存
- PD 均衡使用 count 来算分了，所以会出现 size 差别大的问题.
- BR 建议备份时使用共享存储，可以忽略这些问题
- 或者可以设置 leader-schedule-policy 为 size，默认是 count，这样可以按照size均衡。等均衡后，再用BR备份
可以解释一下 leader-schedule-policy 为 size，默认是 count 均衡的优劣吗？我搜索了文档只看到了设置说明，没有就这个参数做分析，譬如对系统影响大吗？
- leader 的数量更加有代表性吧。leader 是负责读写的，对于每个store的性能，leader 的count数量影响更加多一些，所以用count来均衡应该更加合适。
目前可以点 这个图标自行删除
每天备份后都显示，手动屏蔽不行啊
那先不调整了，感谢
好的，这个功能以后应该会有
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。