FATAL: mysql_stmt_execute() returned error 8028

  • 【TiDB 版本】: 5.7.25-TiDB-v4.0.1
  • 【问题描述】:
    按照 线上负载与 ADD INDEX 相互影响测试 机型测试,同时执行oltp_read_write与add index:
    sysbench oltp_read_write \
    	--threads=16 \
    	--time=300000 \
    	--report-interval=2 \
    	--rand-type=uniform \
    	--rand-seed=0 \
    	--db-driver=mysql \
    	--mysql-db=sbtest \
    	--mysql-host=10.5.74.58 \
    	--mysql-port=3390 \
    	--mysql-user=root \
    	run --tables=1 --table-size=2000000
    
    alter table sbtest1 add index c_idx(c);
    
    错误如下:
    FATAL: mysql_stmt_execute() returned error 8028 (Information schema is changed during the execution of the statement(for example, table definition may be updated by other DDL ran in parallel). If you see this error often, try increasing `tidb_max_delta_schema_count`. [try again later]) for query 'COMMIT'
    FATAL: `thread_run' function failed: ./oltp_common.lua:409: SQL error, errno = 8028, state = 'HY000': Information schema is changed during the execution of the statement(for example, table definition may be updated by other DDL ran in parallel). If you see this error often, try increasing `tidb_max_delta_schema_count`. [try again later]
    FATAL: mysql_stmt_execute() returned error 8028 (Information schema is changed during the execution of the statement(for example, table definition may be updated by other DDL ran in parallel). If you see this error often, try increasing `tidb_max_delta_schema_count`. [try again later]) for query 'COMMIT'
    FATAL: `thread_run' function failed: ./oltp_common.lua:409: SQL error, errno = 8028, state = 'HY000': Information schema is changed during the execution of the statement(for example, table definition may be updated by other DDL ran in parallel). If you see this error often, try increasing `tidb_max_delta_schema_count`. [try again later]
    
    set @@global.tidb_max_delta_schema_count = 5120; 后依然报错
    
  1. 请问您的机器配置如何?
  2. 请上传 grafana 的 over-view tidb detail-tikv 监控
    (1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上,按 ?可显示所有快捷键,先按 d 再按 E 可将所有 Rows 的 Panels 打开,需等待一段时间待页面加载完成。

(3)、使用这个 full-page-screen-capture 插件进行截屏保存

  1. 麻烦上传执行 add index 后一段时间的 tidb.log 日志,多谢。
  1. 机器配置
    | IP | 服务 | 配置 |
    |:-----------|:----------|:--------------|
    | 10.5.74.51 | TiDB1 PD1 | 8C16G50GSSD |
    | 10.5.74.52 | TiDB1 PD1 | 8C16G50GSSD |
    | 10.5.74.53 | TiDB1 PD1 | 8C16G50GSSD |
    | 10.5.74.54 | TiKV1 | 8C32G200GSSD |
    | 10.5.74.55 | TiKV2 | 8C32G200GSSD |
    | 10.5.74.56 | TiKV3 | 8C32G200GSSD |
    | 10.5.74.57 | 监控 | 4C8G100GSSD |
    | 10.5.74.58 | 测试客户端 | 16C16G100GSSD |
名称 版本
系统 CentOS Linux release 7.8.2003 (Core)
CPU Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
  1. grafna 监控

3.日志
tidb1.log (17.6 KB)
sysbench.log (9.4 KB)
执行顺序为先执行sysbench,马上就执行alert table sbtest1 add index

image
应该是因为这个原因 导致的

现在事务确实会存在这个问题,在表的粒度上,这个时间会很短,不会大范围触发事务失败。如果是自动提交的,目前会重试,不存在这个问题的。

5.0 我们也会优化这个问题,https://github.com/pingcap/tidb/issues/17932

执行结果是:

  1. sysbench 程序退出
  2. add index 执行成功
    对于程序影响还是挺大的

这个是以为 sysbench 遇到错误就断开了连接
如果是正常应用程序的话,使用连接池,断开连接之后会自动重连上来可以继续操作