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表中得到
- 不執行大事務