MySQL binlog写入失败90%以上由磁盘空间耗尽或文件系统只读导致，需先用df -h和mount检查分区使用率及是否ro，再验证mysql用户对binlog目录的写权限、路径有效性及大事务缓存超限问题。
MySQL binlog 写入失败，90% 以上是磁盘空间耗尽或文件系统只读导致的，不是配置或权限问题本身，而是它们的表象。
磁盘满或文件系统只读是最常见原因
报错典型如 Disk is full writing './mysql-bin.009642' (OS errno 28 - No space left on device) 或 relay log write failure could not queue，本质都是写不进去。
- 先运行
df -h，重点看 MySQL 数据目录（SHOW VARIABLES LIKE 'datadir';）和 binlog 路径（SHOW VARIABLES LIKE 'log_bin_basename';）所在分区是否 ≥95% - 再跑
mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep -o '\(ro\|,ro\)'，确认没被挂成只读（ro） - 手动测试：用 MySQL 运行用户（通常是
mysql）执行touch /var/lib/mysql/test.binlog && rm /var/lib/mysql/test.binlog，失败则说明写权限或磁盘已堵死
binlog 目录权限或属主错误
MySQL 进程必须对 binlog 文件及其父目录有写权限。注意：不是“能读”，是“能创建、追加、重命名”。
- 查目录归属：
ls -ld $(dirname $(mysql -Nse "SELECT @@log_bin_basename"))，输出里第一列应为mysql:mysql - 查当前 binlog 文件：
ls -l $(mysql -Nse "SELECT @@log_bin_basename")*，所有mysql-bin.*文件属主也得是mysql - 别只改文件权限——目录必须可写：
chmod 755目录即可，chmod 644文件即可；chown -R mysql:mysql整个 binlog 目录更稳妥
max_binlog_cache_size 超限触发写入中断
大事务（比如单条 UPDATE 涉及百万行）会先缓存在内存，超限时直接报 [HY000][10000] binlog write threshold exceeded，不是磁盘问题，但表现一样：事务卡住、写不进 binlog。
- 查指标：
SHOW GLOBAL STATUS LIKE 'Binlog_cache%';，若Binlog_cache_disk_use明显上升，说明频繁落盘，缓存不够 - 临时调大：
SET GLOBAL max_binlog_cache_size = 2147483648;（2GB），但治标不治本 - 根本解法是拆事务：用
WHERE ... LIMIT 10000分批执行，避免单事务撑爆缓存
MySQL 配置路径无效或目录不存在
log_bin 指向的路径如果不存在，或者 MySQL 启动时无法创建该目录，也会静默失败——日志里可能只有一句 Could not open log file。
- 确认配置：
mysql -e "SELECT @@log_bin, @@log_bin_basename;"，拿到路径后ls -d看目录是否存在 - 注意软链接陷阱：
log_bin = /data/mysql/binlog/mysql-bin，但/data/mysql/binlog是个坏软链，ls -l会显示broken - MySQL 不会自动创建多级目录，
/data/mysql/binlog必须提前mkdir -p并chown mysql:mysql
真正棘手的不是报错本身，而是磁盘满之后 MySQL 可能还在往旧 binlog 里硬写，直到 fsync 失败才停——这时候 SHOW BINARY LOGS 还能列出文件，但实际内容已损坏。遇到这种情况，先腾空间，再用 mysqlbinlog --force-if-open 尝试抢救，别急着删文件。
