1209 - The MySQL server is running with the --read-only option so it cannot execute this statement

正在开会,同事电话反映开发库不能写入了,错误信息如下:

1209 - The MySQL server is running with the--read-only option so it cannot execute this statement

一般这个错误有两种原因:

1.连到从库了。从库一般设置为只读。

2.主库的read_only参数被修改为1

 

开发人员是普通用户应该没有权限修改这个参数的值。

DBA也不会去主动修改这个参数。那究竟是什么原因导致开发库不能写入了呢?

 

首先确认了不是开发人员的问题,因为部门的200多位研发都遇到了这个问题。

为了先解决问题,先去查询主库上read_only参数的值。果然read_only被设置为1.

手工修改为0后,问题解决。问题是read_only为什么会设置为1呢?

解决步骤如下:

mysql> select @@read_only;

+-------------+

| @@read_only |

+-------------+

|          1 |

+-------------+

1 row in set (0.00 sec)

 

mysql> set global read_only=0;

Query OK, 0 rows affected (0.00 sec)

 

 

检查mysql的错误日志发现有如下信息:

151231 13:55:11 mysqld_safe Number ofprocesses running now: 0

151231 13:55:11 mysqld_safe mysqldrestarted

 

由此可知MySQL发生了重启。重启的原因是什么呢?

 

检查了系统日志,发现了如下错误:

#tail -100f /var/log/message

Dec 31 13:55:11 mysql2dev kernel: [8680]   500  8680   27084       92   3      0             0 bash

Dec 31 13:55:11 mysql2dev kernel: Out ofmemory: Kill process 12805 (mysqld) score 964 or sacrifice child

Dec 31 13:55:11 mysql2dev kernel: Killedprocess 12805, UID 500, (mysqld) total-vm:13146848kB, anon-rss:7870704kB,file-rss:16kB

Dec 31 13:55:11 mysql2dev kernel: rsyslogdinvoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0

Dec 31 13:55:11 mysql2dev kernel: rsyslogdcpuset=/ mems_allowed=0-1

Dec 31 13:55:11 mysql2dev kernel: Pid:21035, comm: rsyslogd Not tainted 2.6.32-358.el6.x86_64 #1

Dec 31 13:55:11 mysql2dev kernel: CallTrace:

 

由这条错误可知,是由于内存溢出导致了mysql的重启

Out of memory: Kill process 12805 (mysqld)score 964 or sacrifice child

 

那是什么导致了内存溢出呢?

查看了系统的历史命令后发现有同事在做备份,而此时的系统的压力又比较大,且次系统没有设置交换分区,以上原因导致了MySQL的重启。

Swap:            0          0         0

 

为什么重启会导致read_only=1呢? 可能是配置文件中设置了read_only ,检查配置文件

#grep read_only my.cnf

read_only             = on

 

这时开发环境突然不能写入的原因终于水落石出了。

你可能会问,主库为什么设置read_only=on呢,因为原来是一个MMM环境。

现在已经把MMM环境摘掉,所以将配置文件中的read_only 设置为0,至此开发库不能写入问题宣告解决。

### MySQL只读模式下无法执行某些语句的原因 当MySQL服务器以`--read-only`选项启动时,任何非特权用户尝试修改数据库的操作都会被拒绝。这意味着只有具有SUPER权限或SYSTEM_VARIABLES_ADMIN/SESSION_VARIABLES_ADMIN权限的账户可以在这种情况下执行写入操作[^1]。 对于遇到的具体错误信息"Illuminate\Database\QueryException with message 'SQLSTATE[HY000]: General error: 1615 Prepared statement needs to be re-prepared'"而言,这通常不是由只读模式直接引起的;而是可能由于表结构发生变化或其他内部原因导致预处理语句失效而需重新准备。然而,在只读环境中确实会阻止所有试图更改数据的行为,因此如果查询涉及隐式的元数据更新,则也可能触发类似的异常情况[^2]。 为了应对这种情况,可以采取如下措施: - **确认是否有足够的权限**:确保当前使用的账号拥有必要的超级用户权限来绕过只读限制。 - **检查并优化应用程序逻辑**:审查应用代码中的SQL语句,移除不必要的写入操作或将它们移到其他地方处理。 - **调整事务隔离级别**:有时降低事务隔离级可以帮助减少锁定冲突的可能性,从而允许更多的并发读取而不必担心脏读等问题的发生。 - **考虑使用复制架构**:通过设置主从复制机制,让所有的写入都发生在主节点上,而在多个从节点分担读负载,以此提高系统的整体性能和可用性。 ```sql SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; ``` 此外,值得注意的是,在构建SQL查询字符串时应遵循安全编码实践,比如采用参数化查询而非拼接字符串的方式传递变量值给SQL命令,这样不仅可以防止SQL注入攻击还能增强可维护性和效率[^3]。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值