MySQL数据库突然变‘只读’了？别慌，5分钟教你用SET GLOBAL read_only = 0搞定

MySQL数据库突然变"只读"？三步快速诊断与恢复指南

当你正在处理线上业务时，突然发现应用无法写入数据库，日志中跳出"The MySQL server is running with the --read-only option"的错误提示——这种突如其来的状况往往会让初级运维人员手足无措。本文将带你深入理解MySQL只读模式的触发机制，并提供一套完整的应急处理方案。

1. 理解MySQL只读模式的本质

MySQL的read_only参数是一个全局变量，当设置为1时，会禁止普通账户执行任何修改数据的操作（包括INSERT、UPDATE、DELETE、CREATE等），但具有SUPER权限的账户仍可正常写入。这种设计主要服务于以下几种场景：

• 主从复制环境：从库通常设置为只读模式，防止数据不一致
• 数据备份期间：避免备份过程中数据被修改
• 系统维护窗口：防止维护期间意外数据变更
• 磁盘空间不足：自动触发保护机制

常见误触发原因：

1. 运维人员手动设置后忘记恢复
2. 自动化脚本错误配置
3. 磁盘空间达到阈值自动触发
4. 主从切换后配置未同步更新

重要提示：修改read_only参数不会影响已经存在的连接会话，只对新建立的连接生效。这也是为什么有时即使设置了read_only=0，部分连接仍报告只读错误。

2. 快速诊断与应急处理流程

2.1 实时状态确认

首先需要确认当前数据库的只读状态：

-- 查看全局只读状态 SHOW GLOBAL VARIABLES LIKE 'read_only'; -- 替代方案（返回值更直观） SELECT @@GLOBAL.read_only;

预期输出示例：

+---------------+-------+ | Variable_name | Value | +---------------+-------+ | read_only | ON | +---------------+-------+

2.2 权限验证与模式切换

确认状态后，使用具有SUPER权限的账户执行模式切换：

# 使用root账户登录 mysql -u root -p

在MySQL会话中执行：

-- 关闭只读模式 SET GLOBAL read_only = 0; -- 验证设置结果 SELECT @@GLOBAL.read_only;

关键检查点：

• 确保执行账户有SUPER权限
• 检查磁盘空间是否充足（df -h）
• 确认没有活跃的长时间运行事务

2.3 深度原因排查

完成应急恢复后，需要查明只读模式被激活的根本原因：

-- 检查是否处于复制环境 SHOW SLAVE STATUS\G -- 查看最近参数变更记录 SELECT * FROM performance_schema.variables_by_thread WHERE variable_name = 'read_only' ORDER BY thread_id; -- 检查磁盘空间阈值设置 SHOW VARIABLES LIKE 'innodb_read_only%';

常见问题定位表：

3. 高级防护与自动化方案

3.1 预防性监控配置

建议在生产环境部署以下监控项：

• 实时监控read_only状态变化
• 磁盘空间预警（建议阈值85%）
• 主从复制状态检查
• 定期校验参数配置

示例监控脚本：

#!/bin/bash read_only_status=$(mysql -uroot -p${MYSQL_PWD} -NB -e "SELECT @@GLOBAL.read_only") if [ "$read_only_status" -eq 1 ]; then echo "CRITICAL: MySQL is in read-only mode!" | mail -s "MySQL Alert" admin@example.com fi

3.2 安全变更最佳实践

1. 变更窗口选择：在业务低峰期执行配置变更
2. 双重确认机制：重要参数修改需两人复核
3. 回滚方案准备：提前准备好恢复命令
4. 连接池处理：重启应用连接池确保所有连接使用新配置

典型操作流程：

-- 步骤1：通知应用停止新请求 -- 步骤2：查询当前活动连接 SHOW PROCESSLIST; -- 步骤3：温和关闭现有连接（替代KILL） SET GLOBAL interactive_timeout = 30; SET GLOBAL wait_timeout = 30; -- 步骤4：执行参数修改 SET GLOBAL read_only = 0; -- 步骤5：恢复超时设置 SET GLOBAL interactive_timeout = 28800; SET GLOBAL wait_timeout = 28800;

4. 特殊场景处理技巧

4.1 主从架构中的只读控制

在主从复制环境中，需要特别注意：

• 从库默认应该保持read_only=1
• 主库切换时需要同步调整该参数
• 使用以下命令确保复制账号有权限：

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' WITH GRANT OPTION;

4.2 云数据库的特殊考量

主流云数据库服务对read_only参数有额外限制：

4.3 性能优化关联参数

与只读模式相关的性能参数：

-- 优化只读查询性能 SET GLOBAL innodb_read_only_compressed = OFF; SET GLOBAL read_rnd_buffer_size = 256K; -- 监控只读负载 SELECT * FROM sys.metrics WHERE variable_name LIKE '%read%';

在处理完紧急状况后，建议建立完整的应急预案，包括定期演练、监控告警和自动恢复机制。某次我在处理客户生产环境问题时发现，他们的只读模式异常是由一个自定义的监控脚本错误触发的，这个脚本在检测到主从延迟超过10分钟时会自动将主库设为只读——这种"保护"机制反而导致了更严重的问题。