看报错是用的tidb用户的互信，建议用tidb的互信试试，记得给tidb sudo权限

/etc/profile.d/devtoolset-7.sh和/etc/profile.d/llvmtoolset-7.sh 这两个文件应该是之前做scl的gcc版本切换用的，如果不用了可以移动别的目录，重新check一下。

建议先处理一下环境变量的问题，重新check

/etc/profile.d/devtoolset-7.sh: line 1: scl_source: No such file or directory /etc/profile.d/devtoolset-7.sh: line 2: scl_source: No such file or directory /etc/profile.d/llvm-toolset-7.sh: line 1: scl_source: No such file or directory /etc/profile.d/llvm-toolset-7.sh: line 2: scl_source: No such fi…

检查一下环境变量里是否有numactl命令，which numactl

https://docs.pingcap.com/zh/tidb/v7.5/sql-statement-add-index 语法里有写，不仅支持length，还支持mysql 8.0的expression [image]

tiup cluster scale-in cluster_name -N ip:port 如果报错考虑用 --force，会清理该节点的数据，确保机器已经不用了。

不兼容mysql shell，如果嫌麻烦，可以考虑用select into outfile和load data into。 如果表数据量大或者数量多还是建议用tidb的dumpling和lightning。

不是稳定复现就比较难查，网络抓包可以看具体慢在哪，但是持续网络抓包代价比较大。。。之前我们这种问题也是持续查了一个月 8.0的驱动建议用比较新的版本，至少要8.0.33以上。 https://docs.pingcap.com/zh/tidb/v7.5/dev-guide-choose-driver-or-orm#java-drivers

之前tidb 4.0遇到过jdbc版本过低可能会出现该问题，换一下jdbc试试

感觉是跨numa访问导致的cpu负载升高

发一下cdc的完整日志看一下

mysql的行为也是用的sync_log.id，但是mysql有warning显示。 [image] tidb是没有的。

new_collation_enabled的设置关系到底层tikv数据的编码，需要重建集群重新导数据。

这个网络是有问题，延迟太高。另外cpu load也不稳定，需要top检查下哪个进程异常导致的

检查一下业务逻辑，是否有同时操作相同数据的情况

3个tidb，第一个是从1开始，第二个从30001开始，第三个从60001开始，重启第一个，第一个从90001开始

我这边测了一下， TiDB 使用默认的缓存大小是30000，重启其中一个tidb后会rebase当前最大的自增值+30000 [image]

如果不显式指定应该不会出现这种情况。