为什么我们要从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 没题目的。 一次删除多个分区的操纵则会报错： （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
