额。我想问的是下面的那个图,上面的图只是表明测试环境数据量很少。
Size amplification 主要是问这个图
参数edit-config改完会有个确认的动作,有些常规参数会检查是否合规,让重新改或保持原样,有的就没有。
可以从监控看下tidb 内存突然上涨的具体时间,再去慢日志看看,语句可能执行失败了。有topsql,可以更快找sql。
会有这样的日志
Refresh components conifgs
Generate config pd → xxxxxxxxx … Done
扩容的时候有详细的流程日志。是会修改pd的元数据的
升级到6.5.8,就可以了。手动收集需要注意下要在创建分区之后
v6.5以后有动态分区裁剪,tiflash机器性能好,也可以扫的动
不会立即释放,会有一个gogc的动作,一般不会越来越高导致重启,那意味内存泄漏中了bug
set config好像不能持久化,tiup edit-config 再reload确定是持久化的,也是官方推荐的。
读还好,混部的看下机器的cpu,overview 》 system info
应急就绑,不应急代码加。绑了的库还需要注意备份的情况。老版的dumpling就没有备份绑定执行计划的表,新版不知道有没有改进
dumpling是根据rowid拆分导出的,对集群压力不大,导出需要注意下gc时间。超过gc时间会报错的。
一般都是各个算子和逻辑优化都提升了效率,除非中了个别bug,概率太低了。改变写法太笼统了,sql各式各样的,你还不如举例你遇到的具体问题,或许能在社区得到解答。
可以在从库根据对的执行计划绑定,然后你看下有没有SELECT @@LAST_PLAN_FROM_BINDING;
要看你配置的告警规则,如果是组件down了,你改成某某组件就可以了。这是描述信息的问题