版权声明:本文为博主原创文章,转载请附上博文链接! https://blog.csdn.net/woson_wang/article/details/89011647
Otter同步延迟导致数据库反查
背景
在使用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和审计可以看到)
数据库反查从一定程度上提高了数据一致性检验的效率,但是可能会带来新的问题(后续验证后再进行讨论),所以在使用同步通道时,可以采用以下方式进行监控:
- 监控通道的延迟情况,可以从otter.delay_stat表中得到
- 不执行大事务