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 mysqlfindmnt -t ext4,xfs | grep -E "(mysql|data)"- 如果看到类似
/dev/vdb1 /data/mysql/data ext4 ro,relatime 0 0，ro就是罪魁祸首
为什么突然变成只读？常见诱因
文件系统主动切为只读，几乎总是内核在“自保”：
- 磁盘硬件异常（坏道、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，就得立刻换盘，重挂只是掩耳盗铃。
