mysql从库“只读文件系统”错误是操作系统级故障，非read_only参数所致；需先执行mount | grep " / "确认挂载点是否为ro，再用smartctl检查磁盘健康，仅当smart正常时才可remount,rw，否则须更换磁盘。
MySQL从库报“只读文件系统”错误，不是read_only参数导致的，而是底层操作系统层面的文件系统被挂载为只读（ro），MySQL进程无法写入relay log、binlog index、pid文件等——必须先恢复文件系统可写状态，否则任何SQL级操作都无效。
确认是不是真的文件系统只读
别急着改MySQL配置，先验证根本原因。执行mount | grep " / "或findmnt /，看根分区或MySQL数据目录所在挂载点是否含ro（read-only）标识。常见现象包括：
-
/var/lib/mysql所在分区显示ext4,ro而非ext4,rw - 尝试
touch /var/lib/mysql/testfile报错Read-only file system -
dmesg | tail -20里有EXT4-fs error或journal has failed等磁盘异常日志
为什么文件系统会变只读
Linux内核在检测到严重I/O错误（如坏块、断电、SSD固件异常）时，会自动将文件系统设为只读以防止进一步损坏。这不是MySQL主动行为，而是内核保护机制。常见诱因有：
- 磁盘SMART告警未处理，最终触发只读挂载
- RAID卡电池失效导致write-back缓存不可靠，内核降级为ro
- 云主机底层存储故障（如AWS EBS卷i/o挂起超时）
- 手动执行
mount -o remount,ro /但忘记恢复
注意：set global read_only = 0对这种系统级只读完全无效，因为MySQL连relay log都写不进去。
恢复步骤：从内核层开始修复
必须按顺序操作，跳过任意一步都可能失败：
- 先查磁盘健康：
smartctl -a /dev/sda（替换为实际设备），重点看Reallocated_Sector_Ct、Current_Pending_Sector是否非零 - 若磁盘有硬错误，立即停机更换，不要强行remount
- 若只是临时I/O卡顿且SMART正常，尝试
mount -o remount,rw /（或对应挂载点） - 成功后检查MySQL数据目录权限：
ls -ld /var/lib/mysql确保属主是mysql:mysql且非noexec/nosuid挂载选项干扰 - 重启MySQL服务：
systemctl restart mysqld，再执行start slave
容易被忽略的关键点
即使文件系统恢复可写，从库复制仍可能卡住，因为relay log可能已损坏或位置错乱。务必在start slave前检查：
-
SHOW SLAVE STATUS\G中Relay_Log_File和Relay_Log_Pos是否指向一个真实存在的relay log文件 - 若
Relay_Master_Log_File对应的主库binlog已在主库被清理（error 1236），不能直接start slave，需先CHANGE MASTER TO ... MASTER_LOG_FILE=...跳到现存日志 - 云环境（如阿里云RDS、AWS RDS）不提供root访问，遇到只读文件系统只能提工单，自己无法remount
