为什么我们要从MySQL迁移到TiDB？
|
QPS 也不再积压，恢复正常水准：
关于 relay-log，默认是不清理的，就和 MySQL 的 expire_logs_days 一样，这块可以通过 dm-worker 的配置文件来进行配置。 例如将 Expires 配置为 7，代表 7 天后删除： [purge] interval = 3600 expires = 7 remain-space = 15 Expires 来控制保留天数。默认 expires=0，即没有过期时间，而 remain-space=15 意思是当磁盘只剩于 15G 的时候开始尝试清理，这种情况我们极少会碰到，因此这个清理方式其实基本上是用不到的。 所以建议有需要删除过期 relay-log 的小伙伴，直接配置 Expires 保留天数就可以了。 DM 导入完成后，应该提供是否在完成后自动删除全备文件的选项，可以默认不删，由使用者决定是否删除。 从使用者角度来说，全量备份目录无论是全量一次性导入还是 all 增量同步，后续都不会再使用到。 如果 dm-worker 和 TiKV 混部，会导致全备文件占据大量磁盘空间，引起 TiKV Region 评分出现异常，导致性能下降，已转化为 PRM 产品需求。 ④关于 DM 使用期间出现数据丢失的问题 在早期还没有 dm-portal 自动化生成 task 时，我们都是自行编写 DM 的 task 同步文件。后来有了 dm-portal 自动化生成工具，只要图形页面点点点就可以了。 但该工具目前有一个问题是，没有全库正则匹配，即便你只勾选一个库，他底层是默认把每张表都给你配置一遍。 这就会出现当上层 MySQL 新创建某张表的时候，下游会被忽略掉，例如当你使用改表工具 gh-ost 或者 pt-online-schema-change，你的临时表都会被当做为不在白名单内而被忽略，这个问题使用者需要注意。 我们也已经反馈给了官方。未来不久的版本估计就可以修复。 ["skip event"] [task=task_20357] [unit="binlog replication"] [event=query] [statement="ALTER TABLE `360`.`_data_201910_gho` ADD COLUMN `raw_url_md5` CHAR(32) NOT NULL DEFAULT '' COMMENT 'raw_url md5'"] ["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 没问题的。 一次删除多个分区的操作则会报错： （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
