业务反馈在主库上做了一个DDL操作,执行时间很快,但是从机上却一直报主从延迟告警。 分析: 1. 在主机上查看当前的活动线程,发现从机回放进程处于 Waiting for table metadata lock中,但是并没有发现任何其它可疑进程。 ---+---+---+---+---+---+---+---+|Id|User|Host|db|Command|Time|State|Info...
2)Metadata-Lock(元数据锁):MySQL5.5 版本开始引入,主要功能是并发条件下,防止 session1 的查询事务未结束的情况下,session2 对表结构进行修改,保护元数据的一致性。在 session1 持有 metadata-lock 的情况下,session2 处于等待状态:show processlist 可见Waiting for table metadata lock。其具体加锁机制如下: DML-...
# 主库执行DROPTABLEdb1.tbl 语句之前,在从库先用事务阻塞住DROPTABLEdb1.tbl 的重放(会处于 Waitingfortablemetadata lock 状态): #begin;selectcount(*)fromdb1.tblforupdate; # 等待几秒后(大于long_query_time的配置即可),再commitsetglobalslow_query_log=on;setgloballog_slow_replica_statements=on; my...
tbl 的重放(会处于 Waiting for table metadata lock 状态): # begin; select count(*) from db1.tbl for update; # 等待几秒后(大于long_query_time的配置即可),再 commit set global slow_query_log=on; set global log_slow_replica_statements=on; mysql> show variables like '%slow%'; +---+-...
1.DDL未开始,被阻塞,这时SHOW SLAVE STATUS的结果能检查到Slave_SQL_Running_State为waiting for table metadata lock,且Exec_Master_Log_Pos不变; 2.DDL正在执行,SQL Thread单线程应用导致延时增加。这种情况下观察SHOW SLAVE STATU的结果能发现Slave_SQL_Running_State为altering table,而Exec_Master_Log_Pos不变...
发现是执行DDL操作, 状态是Waiting for table metadata lock 也就是有人拿着mdl不放. 使用如下SQL查看MDL (sql来源网络, 几经辗转, 忘了原出处. 先感谢该大佬) 如果对metadata_locks表不熟悉, 就建议看下官网:https://dev.mysql.com/doc/refman/8.0/en/performance-schema-metadata-locks-table.html ...
解决⽅案:建议只读实例、灾备实例规格⼤于等于主实例，如果只读实例、灾备实例承载了⼤量的分析类业务导致实例负载过⾼，需将其实例规格升级⾄合适的配置或者对其性能低效的 SQL 进⾏优化。5、waiting for table metadata lock:原因:长事物运⾏，阻塞 DDL，继⽽阻塞所有同表的后续操作；未提交事物，阻塞...
主库db_core_assets.b_refit_bill_sn大表执行添加索引时候,在添加完成后,从库db-read1 rep_erp 复制通道出现Waiting for table metadata lock 索。 二、具体排查过程 登录db-read1从库show all slaves status\G 第一次检查了下db-read1库的所有的复制通道,发现状态都是yes,但是第二次db-read1从库show all...
在只读实例上,我们可以通过一系列命令查看到复制延迟的原因。 备库复制状态信息中,可以看到当前SQL执行状态为 "Waiting for table metadata lock"。 另外通过会话快照也可以直接看到当前被阻塞的DDL语句: 实例上查看长时间未提交的事务: 数据库智能管家DBbrain会主动发现原因,提交或kill会话后,延迟立即消失: ...
某个worker线程正在执行optimize table操作,处于表级别的MDL LOCK堵塞下,也就是Waiting for table metadata lock。 某个worker线程执行完了自己的工作,但是无法获取提交序列,也就是等待Waiting for preceding transaction to commit 并且2个worker线程无法自动解锁了,因此MTS整体处于hang死状态下。那么需要达到这个状态需要...