The MySQL server is running with the –read-only option so it can...

正在开会，同事电话反映开发库不能写入了，错误信息如下： 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_on 【MySQL只读模式详解】 当收到"The MySQL server is running with the –read-only option so it cannot execute this statement"的错误信息时，这意味着MySQL服务器被配置为了只读模式，不允许执行写入操作。这种错误通常有两种主要原因： 1. **连接到了复制集群的从库**：在MySQL的主从复制架构中，从库通常被配置为只读，以确保它们不会接受修改数据的请求，从而保持数据一致性。如果你的开发团队意外地连接到了从库，就会遇到这个错误。 2. **主库的`read_only`参数被设置为1**：在MySQL服务器的全局配置中，`read_only`参数默认为0，表示允许读写操作。如果被设置为1，服务器将变为只读状态。通常，普通用户无权更改此参数，除非他们拥有相应的管理权限。 在处理此类问题时，首先需要确认是否是开发人员误操作。如果多个开发者都遇到此问题，那么更可能是服务器配置问题。通过运行`SELECT @@read_only;`可以查询当前`read_only`的状态。如果其值为1，可以通过`SET GLOBAL read_only=0;`命令临时关闭只读模式，以解决紧急问题。 然而，服务器为何会自动将`read_only`设置为1，这通常与服务器的异常行为有关。在本例中，MySQL因内存溢出被系统强制重启，导致`read_only`设置生效。从系统日志可以看到，内存不足(`Out of memory`)导致了`mysqld`进程被杀，这可能是因为高负载、备份操作或其他资源消耗大的任务。 在排查过程中，发现系统没有设置交换分区，这意味着当物理内存耗尽时，系统没有额外的虚拟内存可使用，从而增加了内存溢出的风险。此外，历史命令显示有同事在执行备份操作，这在系统压力大时可能导致资源冲突。 至于`read_only`在重启后设置为1，可能是MySQL配置文件(`my.cnf`)中预先设定了`read_only = on`。在某些场景下，如MMM（Multi-Master Replication）环境中，为了防止不一致，可能需要开启只读模式。但在MMM环境移除后，应将`read_only`改为0以恢复正常的读写功能。 在处理这类问题时，确保了解你的MySQL环境，包括复制拓扑、服务器配置以及资源管理策略，这对于快速定位和解决问题至关重要。同时，定期监控和维护数据库服务器，避免因资源不足或配置不当导致的意外中断。在生产环境中，建议配置合适的资源监控和告警机制，以便尽早发现并解决问题。