快了，就在本月

https://github.com/pingcap/tidb/issues/50784 [image]

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

进到 db 目录看下，哪个目录的数据量最大？

确实奇怪，region 个数三个节点都一样，但是就是有一个 TiKV 节点的数据量比较大。你看下数据量多的那个 TiKV 的 gc 是不是正常的？

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

[image] 看描述，SET_VAR是查询块范围的Hint，而不是后续的查询范围生效的 Hint，所以应该是个BUG

好奇最后清理了多少数据量？ 可以关掉GC半年，竟然都没出问题。。

当资源组token耗尽时候，一些小查询因为获取不到token，确实执行时间会变长

看下资源组的监控，是不是当时资源组的token已经被用完了？

其实这个确实也是个关键，后续import/export有考虑加密的事情么？

机器成本确实都差不多，我其实最主要指的是操作的复杂度。在数据量小的时候，其实直接用IMPORT方式来导入数据，还挺方便的。但是在大数据量(上T，甚至几十T)导入的场景下，lightning导入时候必然会使用很大的CPU和内存，其实非常不适合和存在业务访问的tidb-server放在一起，很容易影响正常的业务请求。在这个前提下，肯定是要使用独立的机器来完成大数据量的导入工作。这里就有以下几个问题： 如果lightning作为普通的binary时，我只要把二进制文件拷上去就好了，这台机器即便负载很高也不用担心，因为这是正常现象。 其次这台机器还可以用作其它用途，不需要作为tidb集群的一部分…

这个是两个不同维度的备份，当前我们两种模式都有使用，其中BR是物理备份，我们用来做容灾的；dumpling是逻辑备份，我们主要是归档时候，要将历史数据归档到OSS中，也不希望明文存放。

这里的「链路」是指？其实作为一个用户，我感觉维护独立的二进制工具反而更灵活，理由有下面几点： 当前dumpling / lightning都是单独的二进制文件，我可以在TiDB集群外，找其他机器来执行导出/导入任务。尤其是lightning，在导入时候lightning自身会占用大量资源，如果后续只能在TiDB内部通过SQL方式触发，肯定会影响集群稳定性的。 即便是现在支持将background task限制到某些tidb-server节点，操作成本也比较高，远不如直接二进制灵活，隔离的更彻底。 因为TiDB定位是兼容MySQL的，其实我经常用lightning / dumpling工具来…

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

这个应该其实是在分库分表合并时用的， 多个上游的MySQL source可以用不同的block-allow-list（但是每个source只能选择其中一个）

[image] 过了一会儿，这个region的状态又从pending变成INPROGRESS了