mysql主从切换后应用连不上，八成因未关闭read_only和super_read_only；切换脚本须执行set global read_only = off和set global super_read_only = off，并用select @@read_only, @@super_read_only验证返回双0。
MySQL主从切换后应用连不上，八成是没改read_only和super_read_only
自动灾备不是配好主从就完事，关键在故障时能否让新主库立刻承接写流量。常见错误是只执行了CHANGE MASTER TO、START SLAVE，却忘了把原从库（现主库）的只读开关关掉。read_only=ON默认拦住所有非SUPER权限用户的写操作；而super_read_only=ON更狠，连SUPER用户都拦——如果你用的是MySQL 5.7.20+，它默认随read_only一起开，不手动关，INSERT/UPDATE全会报错ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement。
实操建议：
- 切换脚本里必须包含：
SET GLOBAL read_only = OFF;和SET GLOBAL super_read_only = OFF; - 检查确认：
SELECT @@read_only, @@super_read_only;返回两个0才算生效 - 别依赖配置文件静态设置——动态切换场景下，靠
my.cnf里的read_only=OFF起不了作用，因为启动后可能被监控工具或DBA脚本又设回去了
用mysqlfailover还是自己写Python监听SHOW SLAVE STATUS？
mysqlfailover（MySQL Utilities组件）看着省事，但实际线上几乎没人用：它依赖Python 2.6/2.7，不支持GTID模式下的自动提升，且心跳检测逻辑僵硬，容易误判网络抖动为宕机。真要自动化，不如自己写轻量监听器，核心就两件事：定时查状态、触发切换动作。
实操建议：
- 监听重点字段：
Seconds_Behind_Master（持续>60秒告警）、Slave_IO_Running和Slave_SQL_Running（必须都是Yes），以及Retrieved_Gtid_Set和Executed_Gtid_Set是否一致（GTID场景） - 避免轮询过密：间隔至少3秒，否则在高负载从库上反而加重复制延迟
- 不要只看单点状态——至少采集连续3次结果再决策，防瞬时IO卡顿导致误切
备份恢复脚本里漏掉SET SESSION SQL_LOG_BIN = 0，恢复完主从直接裂开
自动灾备平台必然包含定期物理/逻辑备份 + 快速恢复能力。但很多人在恢复脚本里直接mysql -u root ，结果新库刚恢复完，binlog里就塞满了恢复语句，下游从库一追就报错<code>Duplicate entry或Cannot execute statement——因为恢复过程本身被记录进了binlog，又被复制出去，造成数据冲突。
实操建议：
- 逻辑恢复前必加：
SET SESSION SQL_LOG_BIN = 0;（仅对当前会话生效，安全） - 物理恢复（如xtrabackup）不用关binlog，但恢复后首次启动必须加
--skip-slave-start，等确认位点无误再手工START SLAVE - 恢复脚本末尾补一句
FLUSH BINARY LOGS;，方便后续按时间点截断重放
跨机房同步延迟超5分钟，semi-sync不是万能解药
想靠rpl_semi_sync_master_enabled=ON保一致性？现实很骨感：半同步只保证至少一个从库收到并写入relay log，不保证已执行。跨机房网络波动时，Rpl_semi_sync_master_status频繁在ON/OFF间跳变，主库会退化为异步模式，延迟照旧。更麻烦的是，semi-sync超时参数rpl_semi_sync_master_timeout设太短（比如1000ms），小抖动就降级；设太长（比如10s），主库写入卡死，业务直接受损。
实操建议：
- 优先用
group_replication替代半同步——MySQL 8.0+的MGR自带多数派确认和自动选主，更适合跨机房 - 如果坚持用半同步，
rpl_semi_sync_master_timeout建议设为网络P99延迟的2倍（比如测出来跨机房RTT P99是300ms，这里填600） - 务必配合监控：
SHOW STATUS LIKE 'Rpl_semi_sync%';里重点关注Rpl_semi_sync_master_no_times（降级次数）和Rpl_semi_sync_master_yes_tx（成功半同步事务数），比值突增就是预警信号
自动灾备最易被忽略的，是“切换后谁来通知应用层改连接串”。DNS缓存、连接池预热、JDBC的autoReconnect失效——这些和数据库本身无关的环节，往往才是恢复慢的真正瓶颈。
