你确定要关掉这些监控的话,直接缩容就可以了。edit-config是不能直接缩容的。以后需要这些监控组件,再扩容就行了
可以试试在cluster_slow_query中,用plan_digest 去找执行计划
你这estrows差距也太大了吧,预估就一条数据,回表代价肯定低
第一个能走索引是因为不用回表吧,数据量这么大,回表代价高吧
SELECT /*+ USE_INDEX(user_risk,idx_risk_value) */ risk_value AS risk_t
FROM user_risk
WHERE risk_value = (
SELECT mobile
FROM user
WHERE id = 12345
)
AND risk_item = 1
AND risk_type = 1
AND is_deleted = 0
AND status = 1
如果走idx_risk_value索引确实很好的话,那就直接hint绑定执行计划就行了。
看你配置,是把每个组件都设置了一个ssh port,那你就去每个组件上,把config里面的ssh端口改了,然后用systemctl restart一下,再去tiup 上reload。
索引问题,tikv通过索引account_monitor_type_id,扫描了13366428个key,所以你能看到unified read pool cpu非常的高。合理规划索引,减少key的扫描就没问题了
需要检查一下,备份的数据是不是完整的,备份的时候,每个tikv只会备份自己的leader region的数据,所以要把所有tikv备份的数据汇集到一起才是一份完整的备份数据。
要提醒一下,跨版本不要使用br,最好再版本一致的两个集群之间使用br
你的这个问题其实就是tikv有损坏要怎么恢复,因为pd就算都down了起不来了,也可以用pd recover来重建pd集群。pd起来之后,其他组件都可以拉起了。那么就只用看tikv的损坏程度,是否能够恢复数据了,只要是少数节点丢失,大概率可以正常恢复数据
首先肯定是要去查issue的,看看是不是已知bug,然后看看什么原因造成的什么版本修复的。如果不是已知的,就需要上报了。直接就扩缩容,下回可能又碰到同样的情况。至于删除panic_mark_file,我觉得大概率删了也启动不了tikv,不过能看到更详细的报错信息
一般这个提示就是tikv panic了,去找到panic_mark_file,看看具体报错,可以去GitHub上找找issue。如果不需要,就把这个文件删了,然后重启一下tikv