背景
用户在做技术选型的过程中，总是会对一些数据指标比较关心，特别是在和竞品相比较的时候，更加需要一些有说服力的数据。基于MySQL开发的项目在迁移到TiDB的时候，使用DM同步数据是必不可少的一个环节，我在最近的一次POC中就碰到了这样一个需求，需要评估一个具体的延时时间参考值，因为用户在迁移前期的过渡阶段是把TiDB作为MySQL的从库，有些场景对这个延时很敏感，如果延时太大会直接影响业务。
由于DM并不能直接看到整个链路的延时时间，所以我们必须另辟蹊径找一些办法来实现，以下是我实践过的几种办法，也希望能抛砖引玉，带出其他大佬给社区带来更好的方案。
我的思路比较简单，就是分别根据上下游事务的某个时间点来计算时间差，这个时间差应该要精确到毫秒级，可以从三个方向入手：
-
Binlog Position
-
TiDB General log
-
SQL自动记录时间
接下来就分别看一下如何实现。
基于Binlog Position
DM增量同步是基于订阅MySQL Binlog来实现的，所以首先考虑的办法就是通过Binlog Position来定位某一个事务，只要分别找到同一个Position在Binlog和DM-Worker Log中记录的时间，就可以大致计算出这个时间差。
我使用如下一张测试表来演示这个过程：
CREATE TABLE `table1` (
`id` int(11) NOT NULL,
`mysql_created` timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
在DM Task完全启动成功之后，我们往MySQL里的table1插入一条数据：
insert into table1 values(1,null);
插入成功后我们找到这个事务第一个events的position，这个示例中是1422：
接下来去binlog文件中解析出这段范围内的事务内容，里面有我们需要的时间：
注意看里面的TIMESTAMP内容，意思是事务开始时的时间是21:45:38:572，原始内容精确到了微秒级别，我们这里只取毫秒来计算。
然后拿事务开始的position去dm-worker的日志中搜索相应的内容，当binlog被处理完成后会输出flushed checkpoint字样的内容，我们根据关键字去日志文件中搜索：
从这里可以得到1422被写入完成的时间是21:45:38.603，前后相减一下大概时间差是31ms。
要注意的是，我理解整个链路的过程应该是：mysql(事务开始)->binlog->dm-worker->tidb->dm-worker，相当于TiDB写完后多了一个通知dm-worker的过程。
基于TiDB General log
第二种与前一种类似，我希望能定位到事务实际被TiDB执行完成的时间，这时候可以借助TiDB的GENERAL_LOG功能，用事务号（TSO）去定位。
我们首先打开TiDB实例的General Log开关：
mysql> set tidb_general_log=1;
Query OK, 0 rows affected (0.08 sec)
前半部分和之前一样，还是去binlog文件中找到MySQL事务开始时间戳，这里是22:08:55:419：
然后打开TiBD的Dashboard页面，用如下关键字搜索TiDB节点的日志：
虽然这个页面能看到日志的记录时间，但是存在两个问题，一个是不能精确到毫秒，第二个这并不是事务的提交时间，我们需要进一步根据事务号（TSO）去原始文件中搜索准确时间。
这里的commit时间是22:08:55.434，前后相减的时间差大概15ms。
这里也可以一步到位直接去原始log文件去搜，省去Dashboard查询TSO的过程。
这个链路过程是：mysql(事务开始)->binlog->dm-worker->tidb(事务提交)。
基于SQL自动记录时间
前面两种方法都要各种搜索日志稍微有点麻烦，本着将偷懒进行到底的精神，能不能直观地看出上下游各自的时间？最理想的情况是：一句SQL就能查出来。
从前面的测试中可以发现，时间字段设置当前时间为默认值只对上游生效，同步到TiDB的时候是把实际值传过去了，并不是根据字段定义生成新值。因此，我希望数据到TiBD的时候也能生成当前时间写入某个字段，但是这个字段不能在MySQL中存在，也就是说上下游数据结构不一样。
那DM可以支持这种同步吗？必然是可以的。
关于上下游异构同步官网文档有详细介绍，大家可以参考文档：https://docs.pingcap.com/zh/tidb-data-migration/stable/manage-schema。
我们要使用的带默认值异构同步其实更简单，DM不用做任何操作就能支持。
我们在前面的DM Task完全不动的情况下，只给下游TiDB的table1增加一个字段：
alter table table1 add COLUMN tidb_created timestamp(3) NOT NULL DEFAULT current_timestamp(3);
然后往上游插入一条测试数据：
insert into table1 values(3,null);
插入成功后去TiDB中查询这个表，两个创建时间都能看到了：
是不是非常简单。
这个链路的过程是：mysql(事务开始)->binlog->dm-worker->tidb(事务开始)。
总结
以上3种方式从不同维度计算了一次数据同步的延时情况，这个数据具有一定的参考性。但是使用的过程中要注意每一种的区别，选择你最适合最关心的指标来作为参考。
本文如有不正确的地方欢迎指出，当然了，也欢迎大家推荐更好的方案，一起交流~