看下你那个tikv-detail 下GC几个监控面板 时间长点
compact 释放空间那是针对drop和truncate操作,detele后compact 不释放空间,只是插入新数据能复用原来的region了
对于delete来说,这个操作基本没意义
插入要不用batch,要不就拆分sql一次一部分数据,insert into…select 非常吃内存,很容易oom
人家是delete 你让人insert。
学习下 GC 和 gc in compaction filter ,另外从哪里看的复用原来的region 这个说法
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration#gc-in-compaction-filter-机制
看这个截图你的gc是正常进行的,以下几个建议前面也说过
1、 tidb 有 非事务DML 根据指定的列和行数分批次DML,串行,这个和前面执行delelete sql是不一样的,没有大量的mvcc版本读取,性能比较稳定,你的版本是6.5.1可以用这个。
2. gc in compaction filter后 ,mvcc版本的数据gc是随着compact进行的,过来safepoint interval后看不到马上有GC
3. region合并时有阈值条件的,
max-merge-region-keys
max-merge-region-size
达到这个值后相邻的region才会合并,向右合并,不相邻的合并不了,哪怕没数据,另外如果有tiflash ,也会影响合并。delete后虽然有用数据低于这个值,但是还有mvcc的数据在里面 也要算上的4. lsm tree 收缩空间 就靠compact,compact会清理rocksdb 内标记tombstone的数据(GC后的),有些数据在最底层光上层的compact 是清理不掉的,允许的话还是做手动compact(可以看下面测试):
tikv-ctl --host 10.172.65.156:20161 compact -c write -d kv --bottommost force 还有default cf
感谢解答
1:昨天已经按照你说的非事务dml进行删除了,执行的非常稳定,数据已经删完了
2:我现在手动compact 但是命令行直接卡在这没任何反应,这是命令打错了还是啥,另外–db用不了,在6.5.1这个版本好像只能用-d
参数不同可能是版本差异问题,业务不重要啊白天操作。 这不是卡住了 手动compact 耗时较长,可以看下tikv -detail → compaction reason 和其他compaction相关的监控
有办法停止吗 ctrl+c好像没用
或者不行的话我直接强制下线这个节点?
ctrl+c后 什么都没操作的情况下 过了十来分钟磁盘占用下降了 现在恢复正常,但是看compaction监控好像没发生什么变化,这是被停止了没执行下去么
inserti into 回复的这个回答
gc你贴的问题解决不了任何问题,要不你建个大点表,detele删除所有数据看看gc到最后到底是region少了还是磁盘占用少了,只有drop truncate等操作才能真的回收空间
命令还在吗 直接kill吧 ,另外手动compact时得加下 --bottommost force 要不可能没效果
我上面的回答编辑了下,贴了下图 现在恢复正常了
不太敢搞了 因为是从库 如果小影响的话无所谓的 结果差点集群就崩了 这东西就算放晚上也不好弄吧
直接磁盘100% sql的执行直接干到了30多s 如果加线程限制会有效果么
–threads 可以控制线程数,还有个限速参数 rocksdb.rate-bytes-per-sec
补充一下,compact可以按region来做,根据tikv_region_status获取region列表然后调用compact -r region_id 实现按表的compact,测试下来资源消耗要小于整tikv compact
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。