Otter同步延迟导致数据库反查（使用Otter遇到的问题二）

版权声明：本文为博主原创文章，转载请附上博文链接！ https://blog.csdn.net/woson_wang/article/details/89011647

背景

在使用Otter进行双向同步时，A<---->B双向同步，A为主站点，当在A上执行大事务时，会导致延迟很高，出现反查的情况。

问题描述

Otter Channel配置：

环境为双A同步，即A和B均会对数据进行更新。
一致性反查数据库的阈值为：60秒，即延迟超过60秒，则会反查源端数据库，获取数据的最新版本。

How to repeat?

CREATE TABLE `delaytesttb` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) DEFAULT 'www',
  `addr` varchar(30) DEFAULT 'Hangzhou,Zhejiang,China',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1DEFAULT CHARSET=utf8


----在delaytesttb中插入数据----
mysql> select * from delaytesttb limit 1;
+----+------+-------------------------+
| id | name | addr                    |
+----+------+-------------------------+
|  1 | www  | Hangzhou,Zhejiang,China |
+----+------+-------------------------+
1 row in set (0.01 sec)

----插入大概40万条数据，目的是为了让同步产生大于60秒的延迟（也可以降低阈值，更为方便）----
mysql> select count(*) from delaytesttb;
+----------+
| count(*) |
+----------+
|   490372 |
+----------+
1 row in set (0.10 sec)

批量插入数据

insert into tb1(name,status) select name,2 from tb1;
Query OK, 1 row affected (0.00 sec)
Records: 1  Duplicates: 0  Warnings: 0


select * from tb1;
+----+------+--------+
| id | name | status |
+----+------+--------+
|  2 | abc  |     10 |
|  3 | abc  |      2 |
+----+------+--------+
2 rows in set (0.00 sec)

当Otter发现延迟超过阈值后，会使用主键反查数据库，获取到最新版本，在目标端重放。（整个过程可以通过binlog和审计可以看到）

数据库反查从一定程度上提高了数据一致性检验的效率，但是可能会带来新的问题（后续验证后再进行讨论），所以在使用同步通道时，可以采用以下方式进行监控：

1. 监控通道的延迟情况，可以从otter.delay_stat表中得到
2. 不执行大事务