执行 ddl 的标准步骤

[dcy10000]

如何安全地执行 ddl？

[dcy10000]

一共两种方案，根据优缺点挑选合适的方案，推荐第二种

一、直连 后端 MySQL 执行 DDL

缺点：

• 比较麻烦。需要根据 dble 的配置，分别去不同的后端MySQL的 schema 去执行对应的 DDL。也就是说，如果是 12 分片的表，需要切换 12 个 schema 去分别执行DDL。（建议写个脚本）
• dble 需要 用MySQL表的表结构信息（又称元数据，metadata） 进行 路由计算（比如需要把”*“解引用成所有列）。元数据是从 mysql 加载，执行完 DDL 后dble 并不知道表结构发生变化了，故还需通知 dble 去加载元数据（即执行reload @@metadata）.
  如果没有加载元数据，绝大部分简单查询是可以正确查询的，因为他们不需要用到元数据即可正确下发。但是涉及插入语句（不带columns的需要dble补完的SQL）、多表的复杂查询等通常是需要用到元数据的，没有加载时，当匹配不到正确的列时就会报错：“字段不存在或者元数据不存在"。

优点：

• DML不会报错 “TABLE[XXX] is dong DDL”

是否需要提前停业务

• 由于执行过程中不同节点表结构存在不一致问题，以及执行前后表结构不相同。当执行一些特定的 DDL 时（比如删除表、删除列、修改列名、修改列类型等），使得原本工作正常的 DML 因为找不到正确的列 而报错，这种情况需要提前停业务。即：需要评估你的 DDL 是否影响 DML。

步骤

1. 根据需要停业务
2. 需要根据 dble 的配置，分别去不同的后端MySQL的 schema 去执行对应的 DDL
3. 在 每台 dble 上执行 reload @@metadata。（在 DBLE的官方商业平台有更便捷的按钮可以操作）
4. （可选）验证：执行 check full @@metadata 【https://actiontech.github.io/dble-docs-cn/2.Function/2.1_manager_cmd/2.1.17_check_meta_data.html】 检查table_structure 的值是否正确，还有consistent_in_sharding_nodes和consistent_in_memory是否均为 1。
5. 业务侧切换为 适配新 DDL 的新业务。

PS： reload @@metadata【https://actiontech.github.io/dble-docs-cn/2.Function/2.1_manager_cmd/2.1.07_reload.html】不会使 DML 和 DDL 报错，只是会阻塞。并且可以设置仅对某个表 / 某个 schema 进行 reload，从而缩小 reload 的时间和阻塞的时间。

二、直连 dble 执行 DDL（推荐）

缺点：

• 执行 DDL 的过程中，关于该表的 DDL 和 DML 会报错: “TABLE[XXX] is dong DDL”

优点：

• 方便. 不用找不同的服务器去分别执行，只要在 dble 上执行一遍
• 执行完 ddl 后自动加载对应的元数据

是否需要提前停业务

• 由于执行前后表结构不相同。当执行一些特定的 DDL 时（比如删除表、删除列、修改列名、修改列类型等），使得原本工作正常的 DML 因为找不到正确的列 而报错，这种情况需要提前停业务。即：需要评估你的 DDL 是否影响 DML。
• 如果业务不能接受DML 报错 “TABLE[XXX] is dong DDL”，需要提前停业务。

步骤

1. 根据需要停业务
2. 直接连入dble 的 8066 端口执行DDL 即可
3. 业务侧切换为 适配新 DDL 的新业务。