聚簇表auto_random属性逻辑导入问题

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】

v5.4

【概述】 场景 + 问题概述
使用dumpling导出备份数据,然后使用myloader导入会出现 Invalid auto random: Explicit insertion on auto_random column is disabled. Try to set @@allow_auto_random_explicit_insert = true.提示。
若我临时打开此参数,是否会影响后续TiDB,使auto_random的可用值提前耗尽。

【备份和数据迁移策略逻辑】

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】

【附件】

  • 相关日志、配置文件、Grafana 监控(https://metricstool.pingcap.com/)
  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息
  • TiDB-Overview 监控
  • 对应模块的 Grafana 监控(如有 BR、TiDB-binlog、TiCDC 等)
  • 对应模块日志(包含问题前后 1 小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

1 个赞

不建议自行显式指定含有 AUTO_RANDOM列的值。不恰当地显式赋值,可能会导致该表提前耗尽用于自动分配的数值。既然是迁移历史数据,显示地插入主键,同时又用auto_random也没意义了,可以考虑用高兼容性schema ,shard_row_id_bits和pre_split_regions解决热点问题。

假设有这种场景,我需要修复数据,修复数据的时候dumpling备份,然后修复数据,数据修复失败,需要回滚,此时我使用dumpling备份的数据恢复,此时我会使用myloader恢复,又因为dumpling是显式的指定auto_random值insert语句,这样修复数据以后,是否会表提前耗尽用于自动分配的数值。

假设有这种场景,我需要修复数据,修复数据的时候dumpling备份,然后修复数据,数据修复失败,需要回滚,此时我使用dumpling备份的数据恢复,此时我会使用myloader恢复,又因为dumpling是显式的指定auto_random值insert语句,这样修复数据以后,是否会影响

文档里面关于怎么分配值得解释没有看懂:

自动分配值的计算方式如下:
该行值在二进制形式下,除去符号位的最高五位(称为 shard bits)由当前事务的开始时间决定,剩下的位数按照自增的顺序分配。

试试ligthing导入报这个吗? 我觉得这参数更多的是防止 autorandom人为插入产生热点和与自动分配产生冲突,打开后不插入就没影响。 auto random构成包含 最高符号位+randome位(根据时间hash)+自增值,insert多个value时分配的值是连续的。

igthing恢复不会报这个提示,但是我们想知道,这样显式的插入random值(这些值是tidb之前自动生成的)是否对导致表的自动分配值提前耗尽。

另: auto random构成包含 最高符号位+randome位(根据时间hash)+自增值, 64位,最高位是正负符号位,然后默认五位是random的随机位,这里理解,然后是自增值,这个自增值不理解,因为我测试得出的结果,末尾几位值也不连续。

你上面说的那种修复数据的场景应该是可以的,auto_random 的生成以 8 字节整形为基础。留出高位几个 bit 作 shard,在高位作随机,低位依然保持自增,所以能保证唯一。官方文档中说的是不恰当地显式赋值,可能会导致该表提前耗尽用于自动分配的数值,如果本身都是auto_random生成的,不会重复。
auto_random如何保证全集唯一性参考下这里

导出的是正常插入的,你自己做个测试就明白了,一条条插, 然后一个insert查多个值, auto_random跟时间有关系,数据量应该还达不到这么多,不用担心耗尽的事

同一个事务内的多个insert的auto_random值是连续的。不同事务内的多个insert的auto_random值是不连续的。