[FAQ] DDL 卡住排查经验

[wjhuang2016-PINGCAP]

整个 DDL 的执行流程大致是这样(具体的原理可以参考 【SOP 系列 03】在线表结构变更（Online DDL）)：

第一步，TiDB 收到 SQL 请求，转化成 DDL Job 发出去

第二步，Owner 节点收到 Job 开始分发处理该 Job

第三步，Woker 节点收到 Job，开始执行，并更新进度

第四步，DDL 完成

在排查 DDL 卡住的问题时，我们需要确定 DDL 是在哪一步卡住的。

执行 admin show ddl jobs 如果能看到 DDL 的信息，说明第一步已经完成。

DDL 卡住的问题大多数都是卡在第二步或者第三步。接着我们需要排查是否卡在第二步，也就是确认 DDL owner 是否正常。 执行 curl http://{TiDBIP}:{TiDBPORT}/info/all 可以看到集群的所有 TiDB 节点，上面步骤可以确认有没有 Owner 存在。

如果 Owner 不存在，可能是 TiDB 刚刚 Panic 过， 没有释放在 PD 上面的注册信息，需要等待 lease 过期(默认 45s)才能重新选出 Owner。 如果 Owner 存在，需要检查 Owner 是否在正常地工作。 可以尝试以下两种方法：

1. 抓取 Owner 当前的 Goroutine 栈，看卡在哪个函数中。
2. 检查 Owner 节点的日志，看是否有报错信息。

如果确认过整个流程是在往前推进，这个时候应该不是卡住，只是执行一些步骤慢。 大表加索引慢可能是正常的，因为工作量大。 有些有依赖的 Jobs 前面 block 后面也是正常的。 还可能是 load schema 慢，拿 auto id 慢，等等。

其他： 可以踢掉 Owner，尝试重新选取 Owner，这在遇到 Panic 的旧的 Owner 时比较有用。

1.找到 owner ：curl -X POST http://{TiDBIP}:10080/ddl/owner/resign

2.旁路下线：tidb-ctl etcd delkey [LeaseID] [flags] ownerKey

[AilinKid-PingCAP (Arenatlx)]

可以将此文 【SOP 系列 03】在线表结构变更（Online DDL） 第 7 段也摘出来

[tangenta]

第 7 段：

@TUG_Admin

7.1 各类 DDL 操作预估耗时

在 DDL 操作没有阻塞，各个 TiDB Server 能够正常更新 Schema 版本的情况下，以及 DDL Owner 节点正常运行的情况下，各类 DDL 操作的预估耗时如下：

操作类型	预估耗时
create database / table	1s 左右
drop database / table	1s 左右
truncate table	1s 左右
alter table add / drop / modify column	1s 左右
drop index	1s 左右
add index	取决于数据量、系统负载、 DDL 参数的设置

注：以上为各类操作的预估耗时，请以实际操作耗时为准。

7.2 执行 DDL 会慢的可能原因

• 多个 DDL 语句一起执行的时候，后面的几个 DDL 语句可能会比较慢，因为需要排队等待
• 在正常集群启动后，第一个 DDL 操作的执行时间可能会比较久，可能是 DDL 在做 owner 的选举
• 由于停 TiDB 时不能与 PD 正常通信（包括停电情况）或者用 kill -9 指令停 TiDB 导致 TiDB 没有及时从 PD 清理注册数据
• 当集群中某个 TiDB 与 PD 或者 TiKV 之间发生通信问题，即 TiDB 不能及时获取最新版本信息

7.3 触发 Information schema is changed 错误的原因

TiDB 在执行 SQL 语句时，会使用当时的 schema 来处理该 SQL 语句，而且 TiDB 支持在线异步变更 DDL。那么，在执行 DML 的时候可能有 DDL 语句也在执行，而你需要确保每个 SQL 语句在同一个 schema 上执行。所以当执行 DML 时，遇到正在执行中的 DDL 操作就可能会报 Information schema is changed 的错误。为了避免太多的 DML 语句报错，已做了一些优化。 现在会报此错的可能原因如下（后两个报错原因与表无关）：

• 执行的 DML 语句中涉及的表和集群中正在执行的 DDL 的表有相同的，那么这个 DML 语句就会报此错。
• 这个 DML 执行时间很久，而这段时间内执行了很多 DDL 语句，导致中间 schema 版本变更次数超过 1024（v3.0.5 版本之前此值为定值 100。v3.0.5 及之后版本默认值为 1024，可以通过 tidb_max_delta_schema_count 变量修改）。
• 接受 DML 请求的 TiDB 长时间不能加载到 schema information（TiDB 与 PD 或 TiKV 之间的网络连接故障等会导致此问题），而这段时间内执行了很多 DDL 语句，导致中间 schema 版本变更次数超过 100。

目前 TiDB 未缓存所有的 schema 版本信息。

对于每个 DDL 操作，schema 版本变更的数量与对应 schema state 变更的次数一致。

不同的 DDL 操作版本变更次数不一样。例如，create table 操作会有 1 次 schema 版本变更； add column 操作有 4 次 schema 版本变更。

7.4 触发 Information schema is out of date 错误的原因

当执行 DML 时，TiDB 超过一个 DDL lease 时间（默认 45s）没能加载到最新的 schema 就可能会报 Information schema is out of date 的错误。遇到此错的可能原因如下：

• 执行此 DML 的 TiDB 被 kill 后准备退出，且此 DML 对应的事务执行时间超过一个 DDL lease，在事务提交时会报这个错误。
• TiDB 在执行此 DML 时，有一段时间内连不上 PD 或者 TiKV，导致 TiDB 超过一个 DDL lease 时间没有 load schema，或者 TiDB 断开了与 PD 之间带 keep alive 设置的连接。

7.5 高并发情况下执行 DDL 时报错的原因

高并发情况下执行 DDL（比如批量建表）时，极少部分 DDL 可能会由于并发执行时 key 冲突而执行失败。 并发执行 DDL 时，建议将 DDL 数量保持在 20 以下，否则你需要在应用端重试失败的 DDL 语句。