Data Migration 常见问题

    task 配置中的黑白名单的正则表达式是否支持非获取匹配（?!）？

    目前不支持，DM 仅支持 golang 标准库的正则，可以通过 了解 golang 支持的正则表达式。

    DM 会尝试将包含多个 DDL 变更操作的单条语句拆分成只包含一个 DDL 操作的多条语句，但是可能没有覆盖所有的场景。建议在上游执行的一条 statement 中只包含一个 DDL 操作，或者在测试环境中验证一下，如果不支持，可以给 DM 提 issue。

    如何处理不兼容的 DDL 语句？

    你需要使用 dmctl 手动处理 TiDB 不兼容的 DDL 语句（包括手动跳过该 DDL 语句或使用用户指定的 DDL 语句替换原 DDL 语句，详见）。

    在以下情况中，你需要重置整个数据同步任务：

    此时，relay 处理单元通常会发生错误而退出，且无法优雅地自动恢复，因此需要通过手动方式恢复数据同步：

    1. 使用 stop-task 命令停止当前正在运行的所有同步任务。

    2. 使用 DM-Ansible 停止整个 DM 集群。

    3. 手动清理掉与 binlog event 被重置的 MySQL master 相对应的 DM-worker 的 relay log 目录。

      • 如果是使用 DM-Ansible 部署，relay log 目录即 <deploy_dir>/relay_log 目录。
      • 如果是使用二进制文件手动部署，relay log 目录即 relay-dir 参数设置的目录。

    4. 使用 DM-Ansible 。

    5. 以新的任务名重启数据同步任务，或设置 remove-meta 为 且 task-mode 为 all。

    设置了 online-ddl-scheme: "gh-ost"， gh-ost 表相关的 DDL 报错该如何处理？

    DM 在最后 rename ghost_table to origin table 的步骤会把内存的 DDL 信息读出，并且还原为 origin table 的 DDL。而内存中的 DDL 信息是在 alter ghost_table 的时候进行处理，记录 ghost_table DDL 的信息；或者是在重启 dm-worker 启动 task 的时候，从 dm_meta.{task_name}_onlineddl 中读取出来。

    因此，如果在增量同步过程中，指定的 Pos 跳过了 的 DDL，但是该 Pos 仍在 gh-ost 的 online-ddl 的过程中，就会因为 ghost_table 没有正确写入到内存以及 dm_meta.{task_name}_onlineddl，而导致该问题。

    可以通过以下方式绕过这个问题：

    1. 取消 task 的 online-ddl-schema 的配置。

    2. 把 _{table_name}_gho、_{table_name}_ghc、_{table_name}_del 配置到 black-white-list.ignore-tables 中。

    3. 手工在下游的 TiDB 执行上游的 DDL。

    4. 待 Pos 同步到 gh-ost 流程的位置之后，再重新启用 以及注释掉 black-white-list.ignore-tables。