问题诊断 FAQ

通用问题

1. dtle.gtid_executed 表中是乱码

该表用uuid以binary储存以提升性能。注意查询方式gtid_executed表

协助诊断

遇到问题，首先确认使用了最新稳定版dtle。

将以下内容提供给爱可生工程师，我们将帮助您诊断故障。

通用

• job配置
• 复制阶段(全量/增量)
• 日志（请用gzip压缩）
• 堆栈/内存/运行状态/pprof信息：执行kill -TTIN {dtle_pid}，dtle会自动生成信息文件，存放在/tmp/dtle_dump_[date-time]目录下

服务无法启动,无日志输出，使用如下命令查看std日志

• journalctl _SYSTEMD_UNIT=dtle-consul.service
• journalctl _SYSTEMD_UNIT=dtle-nomad.service

复制停顿、不开始

• 任务有无报错
• 修改日志级别为Debug

性能低、延迟大

• 确认日志级别为Info。Debug日志会大幅降低性能。
• 网络(带宽/延迟)
• 监控项: 队列
• 数据产生量
• 部署结构(节点、dtle/mysql所在)

数据不一致

• 不一致的具体表现、特征
• consul中保存的dtle进度(gtid)
• 目标端 dtle.gtid_executed 表的内容 方法参考
• 源端 show master status 结果
• 表结构、是否有无PK表
• 复制过程中是否有DDL
• 解析源端binlog, 查找不一致数据出现的位置
• 如为双向复制，需确保业务上无数据冲突

binlog purged

即类似如下报错

ERROR 1236 (HY000): The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.

• 目标端 dtle.gtid_executed 表的内容 方法参考
• consul中储存的job gtid
• MySQL show master status;、show binary logs;和select @@gtid_purged; 的结果