MySQL error 1036 occurs when the server detects that a table or its underlying filesystem is read only, blocking any INSERT, UPDATE, or DELETE operations.
MySQL Error 1036: ER_OPEN_AS_READONLY appears when MySQL flags a table as read only because the file system, tablespace, or server itself is in read-only mode. Restore write permissions or disable global read_only to resolve the issue.
Table '%s' is read only
MySQL throws error 1036 when it cannot open a table with write access. The server marks the object read only, immediately halting any modification attempts. SELECT queries still work, but DML statements fail.
The problem surfaces on standalone servers, replicas, and shared hosting alike. Understanding the underlying restriction allows you to restore full read-write functionality quickly.
Error 1036 appears after enabling GLOBAL read_only, mounting a data directory in read-only mode, setting a tablespace as read only, or altering file permissions at the operating-system level. It may also arise if a replica is mis-configured or after a crash that forces InnoDB recovery mode.
Because the error blocks writes, it can stall applications, cron jobs, and ETL pipelines until fixed.
Delaying a fix risks data staleness, application downtime, and backlog growth in message queues. Production workloads depending on the affected table cannot persist new data, leading to potential revenue loss and monitoring alerts.
No. The read-only condition can be global, per tablespace, or due to filesystem permissions for one database.
Yes. A user with SUPER can write even when read_only is ON. However, this should be temporary and done with caution.
A restart resets volatile variables like read_only, but underlying filesystem issues or my.cnf settings will trigger the error again.
Galaxy tracks environment state, warns when connecting to replicas in read-only mode, and surfaces permission issues before writes run, helping users avoid error 1036.
.avif)
.avif){kind=logo}
