TRUNCATE TABLE tableName 报错

在用中间表做数据中转的时候,每次都需要TRUNCATE TABLE tableName,发现会报:

The error occurred while setting parameters

SQL: TRUNCATE TABLE tableName

Cause: java.sql.SQLException: Information schema is changed. [try again later]

; uncategorized SQLException for SQL []; SQL state [HY000]; error code [1105]; Information schema is changed. [try again later]; nested exception is java.sql.SQLException: Information schema is changed. [try again later]

把这条sql语句复制出来,单独执行没有问题。中间表的数据量不大,每个小时只执行一次 TRUNCATE TABLE ,不存在多个线程去执行的问题,请问下为啥会Cause: java.sql.SQLException: Information schema is changed. [try again later] 。?之前在mysql从未发现此问题,以及TRUNCATE TABLE 执行时间有点长,现在在项目中有用到分页去delete 数据,当数据量很大(几十万级别),删除要耗时5min以上,请问下tidb对删除数据、清除数据有啥具体最佳实践。?

tidb 版本信息: Release Version: v3.0.2 Git Commit Hash: 94498e7d06a244196bb41c3a05dd4c1f6903099a Git Branch: HEAD UTC Build Time: 2019-08-07 02:35:52 GoVersion: go version go1.12 linux/amd64 Race Enabled: false TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e Check Table Before Drop: false

您好: 1. 请将业务侧出现问题时完整的报错信息发送一下,包含出错的时间。 2. 请将tidb和tikv的日志都上传下 3. 请问业务连接的时候,是使用的哪种方式,长连接,连接池还是直连 4. 有没有使用lb,HAproxy,f5之类的?

业务连接使用连接池, tidb 使用负载均衡器

tidb 日志: [2019/11/13 03:06:55.153 +00:00] [ERROR] [ddl_worker.go:141] ["[ddl] handle DDL job failed"] [worker=“worker 1, tp general”] [error="[kv:9007]Write conflict, txnStartTS=412513577152282627, conflictStartTS=412513577139175425, conflictCommitTS=412513577192128513, key=[]byte{0x6d, 0x44, 0x44, 0x4c, 0x4a, 0x6f, 0x62, 0x4c, 0x69, 0xff, 0x73, 0x74, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf9, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4c} primary=[]byte{0x6d, 0x44, 0x44, 0x4c, 0x4a, 0x6f, 0x62, 0x48, 0x69, 0xff, 0x73, 0x74, 0x6f, 0x72, 0x79, 0x0, 0x0, 0x0, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x48} [try again later]"] [stack="![](file:///C:UsersAdministratorAppDataRoamingTencentTIMTemp%W@GJ$ACOF(TYDYECOKVDYB.png)github.com/pingcap/tidb/ddl.(*worker).start /home/jenkins/workspace/release_tidb_3.0/go/src/![](file:///C:UsersAdministratorAppDataRoamingTencentTIMTemp%W@GJ$ACOF(TYDYECOKVDYB.png)github.com/pingcap/tidb/ddl/ddl_worker.go:141![](file:///C:UsersAdministratorAppDataRoamingTencentTIMTemp%W@GJ$ACOF(TYDYECOKVDYB.png)ngithub.com/pingcap/tidb/ddl.(*ddl).start.func1 /home/jenkins/workspace/release_tidb_3.0/go/src/![](file:///C:UsersAdministratorAppDataRoamingTencentTIMTemp%W@GJ$ACOF(TYDYECOKVDYB.png)github.com/pingcap/tidb/ddl/ddl.go:445![](file:///C:UsersAdministratorAppDataRoamingTencentTIMTemp%W@GJ$ACOF(TYDYECOKVDYB.png)ngithub.com/pingcap/tidb/util.WithRecovery /home/jenkins/workspace/release_tidb_3.0/go/src/![](file:///C:UsersAdministratorAppDataRoamingTencentTIMTemp%W@GJ$ACOF(TYDYECOKVDYB.png)github.com/pingcap/tidb/util/misc.go:81"] [2019/11/13 03:06:55.216 +00:00] [INFO] [ddl_worker.go:657] ["[ddl] wait latest schema version changed"] [worker=“worker 1, tp general”] [ver=230239] [“take time”=56.227903ms] [job=“ID:294385, Type:truncate table, State:done, SchemaState:public, SchemaID:17438, TableID:294046, RowCount:0, ArgLen:0, start time: 2019-11-13 03:06:33.596 +0000 UTC, Err:, ErrCount:0, SnapshotVersion:0”] [2019/11/13 03:06:55.216 +00:00] [INFO] [ddl_worker.go:624] ["[ddl] schema version doesn’t change"] [worker=“worker 1, tp general”] [2019/11/13 03:06:55.704 +00:00] [INFO] [2pc.go:880] [“2PC clean up done”] [txnStartTS=412513577152282627]

[2019/11/13 03:07:37.808 +00:00] [ERROR] [ddl_worker.go:141] ["[ddl] handle DDL job failed"] [worker=“worker 1, tp general”] [error="[kv:9007]Write conflict, txnStartTS=412513588306509841, conflictStartTS=412513588293402625, conflictCommitTS=412513588398260231, key=[]byte{0x6d, 0x44, 0x44, 0x4c, 0x4a, 0x6f, 0x62, 0x4c, 0x69, 0xff, 0x73, 0x74, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xf9, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x4c} primary=[]byte{0x6d, 0x44, 0x44, 0x4c, 0x4a, 0x6f, 0x62, 0x48, 0x69, 0xff, 0x73, 0x74, 0x6f, 0x72, 0x79, 0x0, 0x0, 0x0, 0xfc, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x48} [try again later]"] [stack=“github.com/pingcap/tidb/ddl.(*worker).start /home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/ddl/ddl_worker.go:141ngithub.com/pingcap/tidb/ddl.(*ddl).start.func1 /home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/ddl/ddl.go:445ngithub.com/pingcap/tidb/util.WithRecovery /home/jenkins/workspace/release_tidb_3.0/go/src/github.com/pingcap/tidb/util/misc.go:81”] [2019/11/13 03:07:37.866 +00:00] [INFO] [ddl_worker.go:657] ["[ddl] wait latest schema version changed"] [worker=“worker 1, tp general”] [ver=230252] [“take time”=53.407182ms] [job=“ID:294449, Type:truncate table, State:done, SchemaState:public, SchemaID:15308, TableID:293961, RowCount:0, ArgLen:0, start time: 2019-11-13 03:07:19.846 +0000 UTC, Err:, ErrCount:0, SnapshotVersion:0”]

TIkv 日志:

[2019/11/13 03:08:06.666 +00:00] [ERROR] [endpoint.rs:454] [error-response] [err=“locked primary_lock: 7480000000000441A75F69800000000000000103800000005DCB63A00380000000002D88D003800000000000002F038000000000257AA6 lock_version: 412513593051316230 key: 7480000000000441A75F69800000000000000103800000005DCB63A00380000000002D892103800000000000002F0380000000002572B4 lock_ttl: 16159 txn_size: 298”]

您好: 看起来存在写冲突,麻烦将完整的tidb和tikv日志下载,上传附件,多谢。

您好,由于附件超过限制没法上传,上传s3 下载

https://devops-data-backup.s3-ap-southeast-1.amazonaws.com/other/tidb.log.zip

https://devops-data-backup.s3-ap-southeast-1.amazonaws.com/other/tikv.log.zip

您好,这两个地址无法下载,是有限制吗?

集群是不是有其他表的DDL操作。。。3.0.4的版本看changelog已经放大DDL的限制从200到1000 。。可以考虑升级一下集群?

可以下载了,麻烦您解决一下此问题,谢谢

好的,正在查看日志,多谢

@湖中芦苇 您好,麻烦确认下,业务端每次 truncate table 都会遇到这样的报错吗

The error occurred while setting parameters

SQL: TRUNCATE TABLE tableName

Cause: java.sql.SQLException: Information schema is changed. [try again later]

同一客户id,每小时不是每次报错,但是每小时执行的时候都有不同的客户id报错,客户id大概有200 左右,每小时报错的客户id总共有十几个。

表命名方式 {客户id}_tableName

我梳理下您的意思,您看下我理解的对不对

  1. 对于每个表 {客户id}_tableName, 每小时会执行一次 truncate table 操作,且不是在同一时刻发生
  2. 这些 truncate table 操作中,会存在十几次,执行 truncate table 时,返回 information schema is changed 的异常

此外,这个现象是一直存在,还是从什么时刻之后开始出现

新增了truncate table 这个逻辑之后就发现了,之前统计数据是没有用到中间表的, 业务逻辑大概是这样的: 数据库按客户id分库的 report_{客户id}

1.每个客户id都会有一个单独线程去执行任务,每个小时会执行小时任务,任务都会先去清除中间表,也就是执行->truncate table report{客户id}.{客户id}_tableName.

2.每个客户id每小时都会有一个小时任务,出现truncate table error问题的不是同一个客户每个小时,而是每小时不同的客户id(可认为是随机)。

3.把出现问题的truncate table sql 语句复制出来,手动去navicat 执行,没有报错出现。

您好: 查看了这个时间的日志:223815:[2019/11/12 06:06:09.963 +00:00] [WARN] [conn.go:668] [“dispatch error”] [conn=2122556] [connInfo=“id:2122556, addr:172.31.32.255:35868 status:2, collation:utf8_general_ci, user:root”] [sql="u0003u0001u0000u0000u0000u0001u0000u0000u0000u0000"] [err="[domain:2]Information schema is changed. [try again later]… ngithub.com/pingcap/tidb/executor.(*DDLExec).toErr…TRUNCATE TABLE report_2959.operation_hour_tmp_report"] 发现在error发生的20s内,单台tidb server有32个truncate table,考虑有多个tidb server,估计还有更多的ddl truncate在这一时间发生。由于短时间DDL频率大,在将DDL放入general queue时产生了write conflict,进而导致部分truncate table重试次数过多而超时,出现information schema is changed的错误。 麻烦将truncate的DDL时间分散一些,不要在同一时间运行过多的DDL,另一方面,我们会在这部分优化,多谢。

收到,了解,谢谢!

您好: 请问打散了DDL的时间吗? 是否方便在返回下每个tidb.log, 确认下是否正常了,多谢。

你好,因为新增中间表导致查询查询统计多了一次,导致统计时间进一步延后,不满足业务需求,现已废除了中间表方案,没有 TRUNCATE 语句了,不好意思,没有相应日志提供了。

好的,多谢