主从切换后sql线程卡在waiting for table metadata lock，是旧主库残留长事务持有mdl锁所致；需通过performance_schema.metadata_locks和innodb_trx定位并kill对应线程，而非重启sql线程或跳过事件。
主从切换后SQL线程卡在Waiting for table metadata lock
这不是配置没改对，而是旧主库上残留的长事务仍持有MDL锁，新主库在重放relay log或接受新写请求时，一碰同名表就阻塞。现象是SHOW PROCESSLIST里大量线程状态为Waiting for table metadata lock，且TRX_STATE为RUNNING的事务启动时间远早于切换时刻。
排查步骤如下：
- 先确认是否真有阻塞：执行
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA NOT IN ('performance_schema', 'information_schema');（需提前启用performance_schema并开启metadata_locks消费者） - 定位长事务：
SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5;，重点看TRX_STARTED比切换时间早得多的记录 - 查清线程归属：
SELECT ID, USER, HOST, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE ID = [trx_mysql_thread_id];，避免误杀复制IO/SQL线程 - 安全终止：优先
KILL非核心应用线程；若确认是旧主残留的DML且无业务影响，可KILL对应线程；DDL类事务必须等它完成或人工中止（如ALTER TABLE无法直接KILL）
切换后新主库报ERROR 1290：The MySQL server is running with the --read-only option
最常见原因是原从库升主后read_only=ON和super_read_only=ON仍生效。MySQL 5.7+默认从库开启这两项，仅改server_id或重启不自动关闭。
检查与修复方法：
- 运行
SELECT @@read_only, @@super_read_only;——两个值都必须为0才正常 - 若
super_read_only=1，必须先执行SET GLOBAL super_read_only = OFF;，再执行SET GLOBAL read_only = OFF; - 临时生效后，立刻检查配置文件
my.cnf，删掉或注释掉read_only=1和super_read_only=1行，避免重启后复现 - 权限要求：需
SUPER或SYSTEM_VARIABLES_ADMIN权限，普通DBA账号可能无权修改
为什么STOP SLAVE; START SLAVE;之后SQL线程仍不恢复
因为START SLAVE只重启SQL线程，但若当前SQL线程正卡在MDL锁上，它不会主动超时退出，默认等待直到锁释放（可能无限期）。此时单纯重启线程无效，必须先清理锁源头。
关键判断点：
-
SHOW SLAVE STATUS\G中Slave_SQL_Running_State显示Waiting for table metadata lock，而非Reading event from the relay log -
Seconds_Behind_Master为NULL，且Slave_SQL_Running为No - 即使执行了
STOP SLAVE; START SLAVE;，状态也不变——说明不是复制配置问题，而是底层锁未释放 - 此时
SET GLOBAL sql_slave_skip_counter = 1;也无效，跳过的是event，不是锁等待
客户端还在往旧主库发写请求（脑裂残留）
VIP未漂移成功、DNS缓存未刷新、连接池未重连，都会导致部分写请求继续打到已降级的旧主库。旧主库此时read_only=ON，直接返回ERROR 1290，但更危险的是——如果旧主库read_only被意外关闭，这些写入会污染数据，引发后续主从冲突。
验证与应对：
- 在旧主库执行
SHOW PROCESSLIST;，看是否有来自应用服务器的活跃Command为Query且State为updating的线程 - 检查应用端连接字符串是否硬编码IP，而非VIP或域名；确认DNS TTL是否足够短（建议≤60秒）
- 连接池（如HikariCP、Druid）需配置
connection-test-query和validation-timeout，确保故障后能快速剔除坏连接 - 切完立即在旧主库执行
SET GLOBAL read_only = ON;加一层保险（即使之前漏关）
真正棘手的不是锁本身，而是锁背后那个没被及时发现的长事务——它可能藏在某个凌晨跑批脚本里，也可能卡在第三方API调用上。别只盯着SHOW SLAVE STATUS，得去INNODB_TRX里翻时间戳。
