版本已经是5.7.6了 刚才看了一下 应该是虚拟列的问题 additional_tag json DEFAULT NULL COMMENT ‘附加标签项’, tag_100004 tinyint(4) GENERATED ALWAYS AS (coalesce(json_contains(additional_tag, _utf8’“100004”'), 0)) VIRTUAL, 在7.5.4没有问题 到7.5.6就有问题了 建一个表包含这两列，然后插入数据后 执行 analyze table 就会报错 runtime error: index out of range [22] w…

当时所有表都analyze过了 只是analyze是一个比较长的过程，这个过程中对业务还是有影响

analyze之后就正常了

整个过程中，升级tikv也没有问题，看起来是升级tidb-server之后开始有问题 怀疑是tidb server没有加载到统计信息 从升级过程中的日志来看 tidb server成功加载了 schema [image] 但是stats 看着是加载失败了 [image] 还有一个这个错误 [handle_hist.go:125] [“SyncWaitStatsLoad meets error”] [errors="["sync load took too long to return","sync load took too long to return","sync loa…

业务插入是 开启general 日志 从日志记录来看 是正常json [image] 但是业务查询 还是显示为base64格式的

起来的时候检查过日志 看起来是能正常的 [image]

升级到7.5.5确实不会被卡住了，进程也正常起来了

cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Silver 4214 CPU @ 2.20GHz stepping : 7 microcode : 0x5003707 cpu MHz : 2700.074 cache size : 16896 KB physical id : 1 siblings : 24 core id : 12 cpu cores : 12 apicid :…

我试一下7.5.5

tiflash日志已补充

当时有上万条这个报错，然后查了一下 很多日志的key表都不是同一个表 [image]

同时也会伴随着如下的日志 [WARN] [prewrite.rs:767] [“commit_ts is too large, fallback to normal 2PC”] [lock=“Lock { lock_type: Put, primary_key: 748000000000081D3D5F6980000000000000010164617933302F7261FF77732F6433307878FF7075622F32303234FF5F31305F30392F39FF6B31397969366468FF676668737236646FFF356261306B347973FF3…

异常的tikv日志 伴随着大量的 如下日志 [WARN] [scheduler.rs:1132] [“[region 2271758687] scheduler handle command: prewrite, ts: 453102623728076289, details: SchedulerDetails { tracker: TrackerToken { shard_id: 24, seq: 39744222, key: 308 }, stat: Statistics { lock: CfStatistics { processed_keys: 0, get: 1, next: 0,…

目前排查进展：确认是gc有问题 检查了 pd 中 region 信息，无空洞 region 找到相关表，但是 key 为索引，找不到索引 id 为 2 的索引。 admin check 相关表无异常 pd-ctl region check down & miss 无异常 后续操作： 尝试重建相关表。重建表后，gc清理仍然不继续推进 [image]

任务无暂停也无法删除 [image] [image] [image]

滚动重启了一下 就正常了

里面只有一个gc_worker本身自己的 所以比较奇怪

嗯嗯 我们后面也会测试一下 6.5版本