主从切换后read_only仍为ON，因该变量不随角色自动变更；必须同时执行SET GLOBAL read_only = OFF和SET GLOBAL super_read_only = OFF，缺一不可。

主从切换后 read_only 为什么还在 ON？

因为 read_only 和 super_read_only 是全局变量，不随主从角色自动变更。MySQL 实例不会在被提升为主库后自动关闭这两个开关——它只认当前配置值。结果就是新主库“逻辑上是主”，但实际拒绝所有写入，应用报错 ERROR 1290 (HY000): The MySQL server is running with the --read-only option...。

必须同时操作 read_only 和 super_read_only

只设 read_only = OFF 不够：它会自动把 super_read_only 也关掉，但如果你之前只开了 read_only、没开 super_read_only，那没问题；可一旦你用的是更严格的 super_read_only = ON（推荐做法），就必须显式关掉两者：

• SET GLOBAL read_only = OFF;
• SET GLOBAL super_read_only = OFF;

顺序无关，但两个都得执行。漏掉任一个，新主库仍处于只读状态。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

自动化工具必须包含 post-failover 步骤

像 MHA、Orchestrator、ProxySQL 或自研脚本，在完成角色切换后，必须连接到新主库并执行上述两条 SET 命令。不能只依赖“检测到主库上线就切流量”——那等于把只读主库暴露给业务。

• 检查点要覆盖变量值：告警规则应监控 SELECT @@read_only, @@super_read_only，主库上任一为 1 就触发告警
• 避免长连接残留：read_only 变更对已存在连接不生效，所以切换后建议滚动重启应用或 kill 长连接（如 KILL CONNECTION xxx）
• 容器/云环境优先用 SET PERSIST：比如 SET PERSIST super_read_only = ON;，它写入 mysqld-auto.cnf，重启不失效，比改 my.cnf 更可靠

别忘了只读不是万能锁

read_only 和 super_read_only 控制的是 SQL 层写入，它们不阻塞复制线程，也不防止磁盘层误操作。真正安全的故障转移，还得配合：

• 切换前确认 Seconds_Behind_Master = 0（连续查 2–3 次）
• 应用层灰度放量，而非全量切流
• 禁用 FLUSH TABLES WITH READ LOCK：它在 8.0+ GTID 环境下易卡死复制，且与高并发冲突严重

最常被忽略的一点：监控脚本本身如果用 SUPER 权限账号连库探活，它可能在只读状态下偷偷执行测试写入，直接破坏一致性语义。