mysql报read-only file system，90%是文件系统被内核强制挂为ro所致，需先检查/proc/mounts确认对应分区是否含ro标志，再根据dmesg错误判断是否硬件故障或需fsck修复，否则调mysql参数无效。

MySQL 报 Read-only file system，90% 不是数据库配置问题，而是底层文件系统真的被挂成了只读（ro）——必须先检查并修复挂载状态，否则改任何 MySQL 参数都无效。

怎么看当前挂载是不是只读

别猜，直接查内核挂载表：/proc/mounts 或 mount 命令输出里找你的 MySQL 数据目录所在分区（比如 /var/lib/mysql 或 /data/mysql/data），确认对应行有没有 ro 标志：

• cat /proc/mounts | grep mysql
• findmnt -t ext4,xfs | grep -E "(mysql|data)"
• 如果看到类似 /dev/vdb1 /data/mysql/data ext4 ro,relatime 0 0，ro 就是罪魁祸首

为什么突然变成只读？常见诱因

文件系统主动切为只读，几乎总是内核在“自保”：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 磁盘硬件异常（坏道、SSD 寿命耗尽、PCIe link down）→ 触发 ext4_abort 或 XFS: failed to write buffer，内核强制 remount ro
• dmesg -T | tail -30 一定能刷出关键线索，比如 end_request: I/O error 或 ataX.Y: failed command: READ FPDMA QUEUED
• 文件系统损坏未修复（如异常断电后未 clean umount），fsck 拒绝自动修复时也会 fallback 到 ro 模式
• 宿主机层面（尤其是 Docker/K8s 环境）挂载时加了 ro 选项，或 volume 权限被限制

怎么临时恢复写入（不重启）

前提是磁盘硬件没彻底报废，且文件系统结构尚可修复：

• 先尝试强制重挂为读写：mount -o remount,rw /dev/vdb1 /data/mysql/data（把设备和路径替换成你的真实值）
• 如果报 mount: /data/mysql/data: cannot remount /dev/vdb1 read-write, is busy，说明有进程占着目录 → 用 fuser -vm /data/mysql/data 查 PID，再 kill -9 或 systemctl stop mysqld 后重试
• 如果 remount 失败且 dmesg 显示大量 I/O 错误，别硬来——停 MySQL，umount /data/mysql/data，再 fsck -y /dev/vdb1（注意：XFS 用 xfs_repair，别混）
• 修复完再 mount /dev/vdb1 /data/mysql/data，然后 systemctl start mysqld

宿主机权限和容器环境要额外盯紧

尤其在 Docker 或 Kubernetes 中，Read-only file system 很可能根本不是 MySQL 自己的问题：

• Docker run 时用了 --read-only，或 bind mount 加了 :ro → 检查 docker inspect 容器名 | grep -A5 Mounts
• K8s Pod 的 volumeMounts 里写了 readOnly: true，或 PV/PVC 的 accessModes 不支持 RWO
• 宿主机上数据目录父路径（如 /data）本身是 noexec 或 nosuid 挂载，某些发行版会连带影响子目录权限判断
• SELinux 或 AppArmor 强制拦截写操作 → ausearch -m avc -ts recent | grep mysqld 查拒绝日志

真正棘手的是硬件级只读：一旦 dmesg 出现重复的 ata 或 nvme 错误，或者 smartctl -a /dev/nvme0n1 显示 Media_Wearout_Indicator 接近 0，就得立刻换盘，重挂只是掩耳盗铃。