磁盘满导致主从配置文件损坏时，mysql无法写入binlog、relay log及更新master.info/relay-log.info，常见报错包括failed to open the relay log等，show slave status中relay_log_file、master_host可能为空或乱码，seconds_behind_master为null；须先清理磁盘空间（如删除旧relay-log.、mysql-bin.等），再执行flush logs和stop slave; start slave;，最后用reset slave all清除损坏状态并重新配置复制。
磁盘满导致主从配置文件损坏的典型现象
磁盘写满后，MySQL 无法写入新的 binlog、relay log 或更新 master.info / relay-log.info 文件，常见报错包括：Failed to open the relay log、Can't open relay log file、IO error reading from master，甚至 mysqld 进程直接崩溃退出。此时 SHOW SLAVE STATUS\G 中的 Relay_Log_File、Master_Host 可能为空或乱码，Seconds_Behind_Master 显示为 NULL。
确认并清空磁盘空间是第一步
不清理磁盘就尝试修复，所有操作都会失败或立即复现。
- 执行
df -h查看根分区或datadir所在分区是否 100% 占用 - 重点清理：
/var/lib/mysql/下的旧relay-log.*、mysql-bin.*（确认已应用且无复制依赖）、error.log和slow-query.log - 临时释放空间后，必须立刻执行
FLUSH LOGS;（主库）和STOP SLAVE; START SLAVE;（从库），避免残留脏状态
重建 relay-log.info 和 master.info 的安全方式
这两个文件损坏后，不能手动编辑——内容含二进制偏移和校验字段，手写极易出错。正确做法是重置复制位置：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
- 在从库上先执行
STOP SLAVE; - 运行
RESET SLAVE ALL;：它会删除master.info、relay-log.info、所有 relay log 文件，并清空复制元数据 - 重新配置复制：用
CHANGE MASTER TO指向主库当前SHOW MASTER STATUS输出的File和Position（注意不是旧位置） - 如果启用了 GTID，改用
CHANGE MASTER TO MASTER_AUTO_POSITION = 1;，避免 position 错位
为什么不能跳过或修复 info 文件本身？
master.info 和 relay-log.info 是 MySQL 内部维护的二进制状态文件，格式不公开，且与 mysql.slave_master_info / mysql.slave_relay_log_info 表同步。强行修改文件内容会导致：
- 下次启动时校验失败，
mysqld拒绝加载复制线程 - position 偏移错位，造成数据重复或丢失
- GTID set 不一致，触发
ERROR 1236或复制中断
真正容易被忽略的是：磁盘满之后，即使空间已释放，relay log 文件可能已截断损坏，RESET SLAVE ALL 是唯一能彻底清除这种隐性损坏的操作。别省这一步。
