为什么我们要从MySQL迁移到TiDB？

["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD INDEX `idx_rawurl_md5`(`raw_url_md5`)"] [schema=flow] 

["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` DROP INDEX `idx_raw_url`"] [schema=flow] 

这里日志可以看到 event 被 skip 了。

⑤关于 DM 使用期间偶发性 1062 主键冲突的问题

query-error task 能看到具体的报错信息，下游看都没有该值：

mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx'; 

Empty set (0.00 sec) 

再去上游看，结果发现也没有值，业务逻辑应该是后来 delete 了：

mysql> select * from client where clientid='82b51e6f6eb64955487f978dd94a2c81e492f6170xxxxxxxxxxxxxxxxxxxxxxxxx'; 

Empty set (0.00 sec) 

因为上游也没有值，去上游看 Binlog 后分析如下：

是先写入，再删除，所以上游没值是可以预期的，但是下游还没有同步到这块，此时也是没有值的，不应该存在 1062 的问题。

当集群有大规模 kv:1062 报错时，或者集群写入压力大时，DM 从结果看无法保证 Binlog 的有序落盘，需确认 DM能不能保证 LVS 下的多个 TiDB Binlog 的每一个 Event 是有序执行的。

只从现象看，只要集群没有大量的 1062 报错，PD 相关的监控值都比较低，DM 也不会出现任何同步报错，反之就出现。

从 Binlog 看就像是第一条 Insert了，还没来得及 Delete，直接 Insert 产生的报错，但报错后那个 Delete 的也完成了，所以这时候我再怎么快也快不到毫秒级，下游看不到所有记录。

解决的办法是将 1062 大量冲突的业务拆分出集群，或 DM 直接写 TiDB 的真实 IP 而不是 LVS。

⑥DM 同步异常

有业务反馈 Drop 分区和 Drop 列时出现同步异常。补充下分区表相关的测试的结果，DM 更多的无法拆分的情况还是在 Drop 这块，普通的 add，modify 没问题的。

一次删除多个分区的操作则会报错：

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!