Debezium系列- snapshot锁表流程详解

背景

采用Debezium 同步MySQL表的时候，同一张表有时候有时会锁表，有时不会锁表。为了弄清楚原因梳理了snapshot的流程

snapshot 流程图

如何排查Debezium锁问题引起的主从延迟？

谁持有的锁？继续查询information_schema.innodb_locks、innodb_lock_waits、innodb_trx表

select * from information_schema.innodb_locks;
select * from information_schema.innodb_lock_waits;
select * from information_schema.innodb_trx;

发现三个表均为空，不要慌继续，performance_schema.metadata_locks表来排查谁持有全局读锁。全局读锁在该表中通常记录着同一个会话的OBJECT_TYPE为global和commit、LOCK_TYPE都为SHARED的两把显式锁。

select * from performance_schema.metadata_locks where OWNER_THREAD_ID!=sys.ps_thread_id(connection_id());

可以看到有两个 LOCK_TYPE: SHARED（共享锁） 和一个 LOCK_TYPE: INTENTION_EXCLUSIVE（意向排它锁）
LOCK_DURATION: EXPLICIT 显示的
LOCK_STATUS: GRANTED 已授予
LOCK_STATUS: PENDING 正在等待被授予
404 这个内部进程阻塞了后面的操作

SELECT B.*,C.OWNER_THREAD_ID,C.OBJECT_TYPE,C.LOCK_TYPE,C.LOCK_DURATION,C.LOCK_STATUS 
FROM performance_schema.threads A,information_schema.PROCESSLIST B,performance_schema.metadata_locks C
WHERE A.PROCESSLIST_ID = B.ID
AND A.THREAD_ID = C.OWNER_THREAD_ID
AND C.OWNER_THREAD_ID = 404

解决方案

方案一
根据找到的 user ,host ,db 等信息，找相关人员问清楚，让执行解锁 unlock tables
方案二
确认没问题后进行暴力破解法 KILL , 然后 unlock tables

Debezium snapshot 问题分析

示例：
有时候Debezium 在 snapshot拿不到锁的原因

操作：执行大查询->FLUSH TABLES WITH READ LOCK [FLUSH TABLES ${table} WITH READ LOCK]
结果：FLUSH TABLES WITH READ LOCK 被阻塞

这种情况，如果大查询没有查询完 FLUSH TABLES WITH READ LOCK 是获取不到锁的，Debezium 在 snapshot的时候拿 flush table 有超时时间，如果超过时间还未执行，Debezium就会人会获取不到全局读锁，这时候走表锁逻辑。准确来说只要FLUSH TABLES WITH READ LOCK 长时间被阻塞，都会引起snapshot获取不到锁。执行DDL语句 和 执行DML大事务（DML语句正在执行，数据正在发生修改，而不是使用lock in share mode和for update语句来显式加锁）都会堵塞

示例2：
操作：FLUSH TABLES WITH READ LOCK [FLUSH TABLES ${table} WITH READ LOCK] ->执行 insert
结果：insert 被阻塞

这种情况，insert 被阻塞直到执行 UNLOCK TABLES; 表被锁引起主从延迟。

如何避免因为锁问题导致主从延迟问题

方案一：
修改源码获取不到锁快速失败任务。
方案二：
snapshot.lock.timeout.ms 配置一个超大值

参考文章

• Flush tabless && Flush tables with read lock
• 全局锁问题排查【flush table with read lock】
• MySQL 全局读锁，MDL锁阻塞查询
• 快速定位令人头疼的全局锁
• SET Transaction Isolation Level Read语法的四种情况