TiDB之DDL学习总结

1 DDL简介

TiDB的DDL变更参考了《Online,Asynchronous Schema Change in F1》论文,使其DDL变更具有异步(asynchronous)和在线(online)的特性,比起MySQL等传统数据库,十分灵活,是TiDB的一大特色

论文引入了4个状态,其中两个外部状态:absent和public;两个内部状态:delete only和 write only。TiDB同样使用上述状态的变迁,达到在线DDL的功能,在状态变迁过程中,集群中最多只能存在两种状态,各个状态的含义,详见论文。

为了简化流程,TiDB首先会选出一个ddl owner 来处理具体处理每个DDL。选举会借助PD中的etcd服进行, 每个TiDB会通过调用Campaign 接口进行 owner 选举。如果选举成功,那么该 TiDB 会周期性的进行续租;当选举不成功,会watch ownerKey,一旦ownerKey有变动(如owner宕机),会触发再次竞选。只有成为ddl owner才有权执行DDL。可以通过直连TiDB执行 admin show ddl;命令来查看当前owner节点。

所有的DDL操作都会存储在KV上的ddl job queue中,ddl owner 会依次取出ddl job执行。执行完成的DDL会被移动到ddl history job queue中。如果该DDL job被移动到了ddl history job queue中,则表示该DDL已经执行完成。

DDL整体架构如下图所示,详细流程参考 DDL 源码解析

2 常见DDL的状态迁移

创建库:
absent -> public
删除库:
public -> write only -> delete only -> absent
创建表:
absent -> public
删除表:
public -> write only -> delete only -> absent
创建视图:
absent -> public
删除视图:
public -> write only -> delete only -> absent

添加列:
absent -> delete only -> write only -> write reorganization -> public
删除列
public -> write only -> delete only -> delete reorganizeation -> absent
新建索引:
absent -> delete only -> write only -> write reorganization -> public
删除索引:
public -> write only -> delete only -> delete reorganizeation -> absent

其中的删除操作,会将对应的信息存储到gc_delete_range表中,在GC阶段真正处理。

恢复表:
absent  ->write only -> public

3 DDL状态查看相关命令

DDL操作官网文档很详细,这里就不再赘述了。

admin show ddl;
admin show ddl jobs;
admin show ddl job queues xxx
admin cancel ddl jobs xxx

4 DDL调优

4.1 参数

tidb_ddl_reorg_worker_cnt default 16
tide_ddl_reorg_batch_size default 1024

当执行add index时,该集群上有频繁的写入操作,则add index 操作会对写入有一定的影响,可能会造成写入冲突。此时应该合理的降低上述两个参数的值,减少DDL造成的负载。当集群系统主要是频繁写入时,可以适当的调高参数,增加DDL的速度,此时对读取性能影响不大。

相关性能测试参考 线上负载与 ADD INDEX 相互影响测试

更全的DDL相关参数的传送门:传送门

4.2 DDL执行慢 和 正常耗时

不赘述了,参考官网相关内容就好啦:传送门

5 DDL的限制

同样不赘述了,参考官网相关内容就好啦:传送门

1赞