把 export-fix-sql 设置为 false 再试下， 我之前遇到过一次，关闭为 false 就能跑过了。 具体原因忘了，印象中是在生成 fix-sql 时候，源表的数据发生变化导致数组越界。

梳理了一下，是因为上游给业务了 create table权限，但是上面执行了 create table if not exists，而这个 SQL 里包含的表结构是老的表结构？

恭喜恭喜

这是截图效果对比图 [image]

对比了下显示效果，发现在1080P 分辨率下，看起来总觉得怪怪的。4K 分辨率就好很多了。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

只要是两次任务执行期间，有 DDL 修改的都有可能报错。 其实start-task有个参数是--remove-meta，会自动清理缓存的。 不过对你来说，这个任务就需要重建了，可能得重新找个 binlog 位置了。 另外一种方案是写个脚本，先用binlog-schema list获取所有同步的表，然后都刷新一下缓存。

应该是历史上有同名任务，而那个任务里的 schema 是老的schema 导致的。试下用binlog-schema命令更新下schema tracker中的缓存 Use "dmctl binlog-schema [command] --help" for more information about a command. » binlog-schema update --help update tables schema structure Usage: dmctl binlog-schema update <task-name> <database> <table> [schema-…

当前还不行， 一、IMPORT INTO 只支持导入空表中；二、IMPORT INTO SELECT的语法在7.5 还不支持，是8.1才支持的。 7.5的场景，可以试下上面提的 BATCH ON语法

我线上设置的是24小时，目前没发现有什么问题。 有次还真的跟业务兜了个底，大大的缩短了业务的回退时间。

@ShawnYan @Kongdom @Billmay表妹 大佬太多了，三个真的不够。。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

不过看描述，也是支持utf8字符集的， https://docs.pingcap.com/zh/tidb/stable/user-defined-variables [image]

在 TiDB 7.5.3试了下，确实会报错 mysql> select 1 INTO @MySqlConnectorSleep; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your TiDB version for the right syntax to use line 1 column 40 near "@MySqlConnectorSleep" mysql>

issue里说的其实很明白了，@MySqlConnectorSleep到底算不算一个标准的变量命名，这个库以这种方式来命名变量，也太 trigger 了。。

https://docs.pingcap.com/zh/tidb/stable/br-pitr-guide 我理解，你应该需要的 PiTR 功能，都是 BR 提供的逻辑，跟 binlog 组件没有关系

坚决杜绝灌水行为

确实可能是，DM 是直接复用 tidb-server 的语法解析模块，不过记得应该 6.X 某个版本貌似修复了，语法解析失败不会在 DM 处直接出错，而是交到执行阶段由 tidb-server 判断是否能执行成功。 可以在测试环境使用最新的 dm 版本试下，看还会报错么。

看起来和我之前遇到的一次问题差不多，可以通过select * from mysql.stats_meta 这个 SQL 来查询下，统计信息有没有真正写入到 TiKV 上进行物理存储，看到底是 tidb-server 启动时候加载统计信息有问题，还是从物理上统计信息就消失了。 PS：mysql.stats_meta这个表里只有table_id字段，要和information_schema.tables的tidb_table_id字段 join 一下