分布式数据库中间件 DDM-DDM SQL使用规范:DDL

时间:2023-11-10 17:32:08

DDL

  • DDL执行时机

    对已有表进行DDL操作时建议放在业务低峰期进行。

  • 分片数

    创建新拆分表时建议结合实际数据量进行合理预估,总分片数满足需求即可。不建议使用超出实际需求的分片数,拆分表分片数并非越多越好

  • 高危DDL

    进行高危DDL时请仔细校验SQL后谨慎操作,如DROP TABLE, TRUNCATE TABLE等操作。

  • DDL失败修复

    DDL命令如遇报错,可以使用"check table 表名"命令对各个分片表结构进行校验,识别出失败的分片进行针对性修复。如ALTER TABLE命令遭遇失败可以在命令前添加/*+allow_alter_rerun=true/,开启ALTER语句的幂等可重入执行后重试,直到check table 命令提示各个分片表结构达到一致则可认为执行成功。

  • MDL锁导致执行DDL报错
    • 背景:为保证DDL的可用性,DDM内部在执行DDL前会检查底层RDS相关表是否存在MDL锁。 若存在MDL锁,,则DDL会提前报错退出。
      metadata lock exists, one of MDL is [%s],DDL operation can not proceed, please use 'show metadata lock' to check current mdl, and use 'kill physical threadId@host:port' to clean it
    • 可能出现的问题:若系统中存在慢SQL,执行时间为几分钟不等,那么可能被MDL锁所阻拦,无法执行DDL。
    • 解决方案1:在DDM控制台提高参数“ddl_precheck_mdl_threshold_time”的大小, 如提高到30分钟(1800秒)。

      “ddl_precheck_mdl_threshold_time”表示DDL允许MDL锁持有的最大时长。持有超过这个时间长度的MDL锁,DDL才会报错,默认值为120秒。

    • 解决方案2:执行show metadata lock查看是否因为持有慢事务的MDL锁阻塞了DDL的执行。若存在阻塞, 可以使用kill physical threadId@host:port 来关闭底层慢事务。配合/*+allow_alter_rerun=true*/的hint, 以及check table来查看和执行,直到DDL彻底执行完。

      threadId为物理层RDS的线程id,host和port分别为物理层RDS的ip和端口。

  • DDL长时间卡死

    在业务低峰期执行DDL时如果遇到长时间卡死情况,请另开会话执行xa recover命令查看是否有慢事务存在,如存在慢事务挂起请及时联系值班人员解决。

support.huaweicloud.com/bestpractice-ddm/ddm_01_0014.html