把 export-fix-sql 设置为 false 再试下, 我之前遇到过一次,关闭为 false 就能跑过了。 具体原因忘了,印象中是在生成 fix-sql 时候,源表的数据发生变化导致数组越界。
梳理了一下,是因为上游给业务了 create table权限,但是上面执行了 create table if not exists,而这个 SQL 里包含的表结构是老的表结构?
对比了下显示效果,发现在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小时,目前没发现有什么问题。 有次还真的跟业务兜了个底,大大的缩短了业务的回退时间。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
在 TiDB 7.5.3试了下,确实会报错
mysql> select 1 INTO @MySqlConnectorSleep;
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 "@MySqlConnectorSleep"
mysql>
issue里说的其实很明白了,@MySqlConnectorSleep到底算不算一个标准的变量命名,这个库以这种方式来命名变量,也太 trigger 了。。
确实可能是,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 一下