此话题已在最后回复的 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了

不过这个监控没有找到，能给下详细的在grafana哪个dashboard上么？

PD里对应的Rule是： { "group_id": "TiDB_DDL_45199", "group_index": 80, "group_override": true, "rules": [ { "group_id": "TiDB_DDL_45199", "id": "partition_rule_45199_0", "index": 40, "start_key": "74800000000000b0ff8f00000000000000f8", "end_key": "74800000000000b…

[image] 总共有三个DC，这里截图了一个dc的拓扑，其他两个DC也都是类似，每个DC分了有三类Label，但是感觉和这个关系应该不大，毕竟用的是-disk排除某类Label

是的，真实需求就是这样，不过测试时候发现可能哪里设置的不对，一直没有生效。

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

昨天下午修改的，到现在已经超过12小时了。另外这个表是个测试表，总数据量才几十万，其实最主要是Operator没有生成，不知道现在是卡在哪个步骤了。