新DDL执行引擎引入了任务管理功能,外部行为与之前版本相比有所变化。本文将介绍相关的注意事项与使用限制。

注意事项

  • DDL正常执行成功时,无需关注DDL任务的状态,已成功完成执行的DDL任务会被自动清理。
  • 建议DDL执行成功后,立即执行CHECK TABLE检查逻辑表的一致性。
  • 通过DDL任务管理语句恢复、回滚或删除DDL任务后,建议执行CHECK TABLE检查逻辑表的一致性。
  • DDL执行失败时,会返回导致失败的错误码和错误信息,您可以通过SHOW DDL查看处于PENDING状态的DDL任务失败的原因(即REMARK字段中记录的信息)。
    注意 建议您在找到并解决导致DDL任务失败的因素后,再尝试执行DDL任务管理语句进行恢复、回滚或删除操作,否则DDL执行可能仍会失败。
  • 若DDL执行失败,对应的DDL任务处于PENDING状态时,出于保护目的,目标表会处于不可访问状态(SHOW TABLES等操作无法显示,DML等操作可能会收到Unknown tabledoesn't exist之类的报错),直到DDL任务通过恢复或回滚等方式使目标表达到一致性的状态后,该表才可以被正常访问。
  • 当为CREATE TABLE指定IF NOT EXISTS或者为DROP TABLE指定IF EXISTS条件时,一些执行过程中的错误不会导致 DDL失败,但会记录在warning警告中,请注意DDL执行后是否返回warning数量的消息(例如1 warning),并用SHOW WARNINGS语句检查警告,避免遗漏重要的信息。
  • 通过DMS等客户端工具执行DDL时,若无法评估DDL需要的执行时间且客户端工具本身带有超时中断连接(客户端与DRDS之间的连接)的设置,为避免DDL由于超时中断连接而无法被继续执行,您可以启用PURE_ASYNC_DDL_MODE异步模式,执行DDL后立即返回,并继续通过SHOW DDL查看DDL任务状态。

使用限制

  • 仅支持CREATE TABLE和RENAME TABLE两种DDL回滚操作。
  • 不支持对处于PENDING状态的任务执行恢复(RECOVER DDL)和回滚(ROLLBACK DDL)的组合重复操作。例如,先回滚失败任务,回滚失败后再对任务进行恢复操作。此类组合操作有可能造成逻辑表的不一致状态,如果遇到此类复杂场景,请。
  • REMOVE DDL要在非常确定安全性的前提下谨慎使用,若不确定则不应执行REMOVE DDL,误用可能造成DDL任务的中间状态暴露,出现逻辑表不一致的情况。如果因为误用REMOVE DDL产生问题或不确定的状态,请。
  • 默认拆分表的单个物理库允许创建最多128个分表,您也可以通过如下参数调整上限。
    mysql> create table test_mdb_mtb (c1 int not null auto_increment primary key, c2 varchar(10), c3 date) dbpartition by hash(c1) tbpartition by hash(c1) tbpartitions 129;
    ERROR 4647 (HY000): [f5bd90594800000][30.25.86.55:8527][JICHEN_LOCAL_APP]ERR-CODE: [TDDL-4647][ERR_TABLE_PARTITIONS_EXCEED_LIMIT] The number of table partitions '129' exceeds the upper limit '128'. Please specify less table partitions or adjust the value of the parameter MAX_TABLE_PARTITIONS_PER_DB.
    mysql> /*+TDDL:cmd_extra(MAX_TABLE_PARTITIONS_PER_DB=400)*/create table test_mdb_mtb (c1 int not null auto_increment primary key, c2 varchar(10), c3 date) dbpartition by hash(c1) tbpartition by hash(c1) tbpartitions 129;
    Query OK, 0 rows affected (2.64 sec)
  • DDL执行引擎内部的任务队列,最多允许堆积65535个PENDING状态的DDL任务,超过此上限则无法执行DDL,需要通过REMOVE DDL谨慎清理可删除的遗留任务,该数量限制无法通过参数调整上限。