为什么truncate也会创建region

如题,单pd单tikv,create一张表后再truncate,region数量增加2

truncate,等于是 drop 后,在create…

table id 会变化,你可以试试

这个时候,region 肯定会按照 默认的配置也 create

那默认配置下每个表一个region,truncate后创建了新region,老region是不是就是没有任何绑定的region了,而且隔了10多20分钟,region也没有合并,而且truncate本意是只删除表数据不删表结构,如果表有索引,这样的话索引会不会被删了

region 会变成 empty ,,然后通过 PD 的调度来对 empty region进行合并。这块的文档挺多的,可以参考处理下,关键是各项配置是否到位

  1. 是否允许跨表合并

  2. 合并开关是否打开…

  3. 是否有合适的合并区间

还有一些其他的条件也会影响合并

然后,索引也是region,也会新建了… (数据都没了,索引肯定也要清理掉了)

TRUNCATE 语句以非事务方式从表中删除所有数据。可认为 TRUNCATE 语句同 DROP TABLE + CREATE TABLE 组合在语义上相同,定义与 DROP TABLE 语句相同。 换句话说是废弃掉了原有的region并重建,table id 也会发生变化。

1赞

table_id真的会变呢

tidb中有flashback机制,所以删除的表或者truncate的表应该在后台还会存在一段时间,用新的表id看起来是很合理的。

所以recover和flashback应该都是可以恢复TRUNCATE操作的,TRUNCATE本质上和DROP差不多,不是视频课里描述的那样,只有flashback能恢复truncate:joy:

empty region,是不是可以算作占位符,占了key的范围,并且在这个范围内的key,还存不进来?

不是哪个概念,region key 范围是创建的时候,就定义了,左闭右开的原则

只有达到这个原则下的region 才能合并,不能向左合并

这些资料去看最佳实践的文档,里头有… 值得好好学习

recover 和 flashback 本质上差不多,recover更久远一些。

PD 调度策略最佳实践 里有这么一段解释了不会合并 Truncate 这类操作导致的空 Region

创建过大量表后(包括执行 Truncate Table 操作)又清空了。此时如果开启了 split table 特性,这些空 Region 是无法合并的,此时需要调整以下参数关闭这个特性:

  • TiKV: 将 split-region-on-table 设为 false ,该参数不支持动态修改。
  • PD: 使用 PD Control,根据集群情况选择性地设置以下参数。
  • 如果集群中不存在 TiDB 实例,将 key-type 的值设置为 rawtxn 。此时,无论 enable-cross-table-merge 设置如何,PD 均可以跨表合并 Region。该参数支持动态修改。 config set key-type txn
  • 如果集群中存在 TiDB 实例,将 key-type 的值设置为 table 。此时将 enable-cross-table-merge 设置为 true ,可以使 PD 跨表合并 Region。该参数支持动态修改。
config set enable-cross-table-merge true

但是在tikv里面region不允许有间隙,也就是说不管region是不是空region它们都是连续的,那像truncate这种操作导致的空regioin,已经与truncate之前的表没有关系了,它还有没有范围的,后面操作出现的key如果在这个范围内,是否会存入这个空 Region 中并与相关的表做关联呢?

一旦允许跨表后,region 就没了逻辑上的约束(专属于某个 Table),基本上都会有作用了(所有的 table 都可用)

后面就各种观察就好了,凡是能合并的region,调度器会帮你搞掂的

懂了,还有个问题,如果pd 挂了,不管是tikv 还是tidb,除了缺少了 pd 提供的功能外,基本的增删改查是否可用的

pd全挂了就无法连接了,也提供不了读写了

我们用 tikv 试了下,因为缓存的关系吧,运行时 pd 挂了还是可以读写,只是没了 pd 的功能,不过启动的时候确实是需要 pd

刚试了下,确实是可以连接,但是对表的读写操作应该不行。

没 TSO 支持,tidb 基本不可用了

就算 裸 Tikv 也是需要 PD 来支持的…

我们压测场景下中途把 pd 给全关了, 整个 tikv 的 tps 还提高了