这里的锁是不一样的，乐观锁和悲观锁中的读写冲突指的是，两阶段提交的时候，Prewrite 加的锁会阻塞能看到该锁的事务的读，原因是写下该 lock 的事务可能已经获取了 commit ts，且 commit ts 小于看到锁的事务的 start ts，这时候 select 都要等锁。 你描述的悲观锁不用等锁，指的是悲观锁两阶段提交前，会加一把锁，确保两阶段提交的时候不会发生 write conflict 的错误，这里的事务一定还没获取 commit ts，所以悲观锁不会阻塞读（和乐观锁一样，悲观事务提交仍要走一遍完整的 Percolator 提交流程，只有当所有悲观锁被 Prewrite 成…

挺奇怪的，从你描述的业务上来说似乎 mvcc 不多。我建议可以通过 tikv-ctl 看下你日志中暴露出来的那个不能分裂的大 region 的属性，看下输出的情况实锤下 mvcc 是否过多 https://docs.pingcap.com/zh/tidb/stable/tikv-control#查看-region-属性 。 如果过多的话，可以通过 tikv-ctl 执行下这个 region 的 compaction，https://docs.pingcap.com/zh/tidb/stable/tikv-control#手动-compact-单个-tikv-的数据 ，使用 force 选项。…

这个集群是什么版本呢？另外业务上是不是有对同一行大量更新的操作？从而同一个 region 产生了很多 mvcc 数据，TiDB 在设计时，要求同一个 key 所在的所有 mvcc 版本数据只能落在一个 region 里面，所以如果 TiDB 中某一行数据更新过于频繁，会导致版本堆积过多而出现大 region 的情况（大于 1 G）。如果是这种情况的话，有可能碰到了 https://github.com/tikv/tikv/pull/15284

lpad 是 null 这个我看了下，mysql 5.7 也是 null，会提示 Result of lpad() was larger than max_allowed_packet (4194304) - truncated，mysql 8.0 是可以返回预期的字符串的。这个算是 mysql 和 tidb 的一些兼容性方面，可以提个 issue 先 track 下

我刚看了下。 之所以在 titan 没有看到文件，是因为写入的数据还在 cache 中，没有实际落盘，可以写多点就可以看到效果了。 第二个问题 RROR 1048 (23000): Column ‘pd’ cannot be null 报错，关闭 titan 也存在。可能是 tidb 的 bug，超过了某个长度处理不了 [image] mysql> select lpad('a',6553555,'a'); +-----------------------+ | lpad('a',6553555,'a') | +-----------------------+ | NUL…

/etc/tikv/tikv.toml 这里的内容是什么，我怀疑你单独配置了 raftdb-path，而这个可能不是持久化的存储，pod 重启后，就没了

tikv 的配置参数是什么样的

前端任务和后台任务用的都是 default 资源组么

升级前后的 clinic 监控麻烦收集一下

可以同步，大部分情况可以正常使用，有一些已知的兼容性问题还没有解决

https://docs.pingcap.com/zh/tidb/stable/maintain-tidb-using-tiup#修改配置参数 这样修改。具体修改什么参数，上面回复有链接提到

可以配置一下 https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#temp-dir-从-v630-版本开始引入 换个目录。避免系统定时删除

我试了下没有复现出来。看到一个可能的问题，如果你是升级上来的集群，可以试试这个 issue 描述的方法 https://github.com/pingcap/tidb/issues/46551

truncate 相当于重建一个新的表（观察 table_id 变化了），正常情况下新表会很快 tiflash 副本可用。会不会是数据库中 ddl 任务比较多/重，影响了？ 手动新建一个表，设置 tiflash 副本观察一下什么时候 ready 呢？另外你 truncate 的表是多大的

https://github.com/tikv/client-go/blob/master/internal/locate/region_request.go#L1684 (master 版本，行数跟报错不一样，不过也不影响看一下），这里 store 作为一个指针没有初始化。修复的话，可以在使用前判断一下 nil。先提个 issue track 一下 https://github.com/pingcap/tidb/issues/48076

麻烦把这条报错语句当时的 tidb 错误日志发一下，也就是 panic 的错误栈，方便问题分析

tiflash 这边不允许垮表 merge region，如果带有 tiflash 副本的比较小的 partitions/tables 数量基本和当前 empty regions 数量一样的话。估计就是这个限制了

是不是有很多小表或很多 partitions，另外设置 tiflash 副本的都是哪些类型的表呢

的确是个 bug，属于 resource group ddl 原子性的问题。记录一个 issue track 一下 https://github.com/pingcap/tidb/issues/45050