MySQL怎么排查Binlog日志写满导致服务器根分区100%打死-LINUX-PHP中文网

90%以上根分区100%的MySQL服务器问题源于mysql-bin.*文件未自动清理，主从延迟或配置失效致日志无限堆积；需先用df、du定位，再查binlog_expire_logs_seconds是否生效，PURGE前必须核对主从安全水位线并检查大事务占用句柄。

mysql怎么排查binlog日志写满导致服务器根分区100%打死

直接结论：90%以上根分区100%的MySQL服务器，问题就出在mysql-bin.*文件没被自动清理，且主从延迟或配置失效导致日志无限堆积。

别猜，先定位。很多“磁盘满”其实是/var/lib/mysql下mysql-bin.*文件占了上百GB，但df -h只显示/分区100%，容易误判为系统文件问题。

MySQL默认expire_logs_days = 0，等于永不清除——这不是bug，是设计。8.0+还废弃了这个参数，只认binlog_expire_logs_seconds，设了expire_logs_days反而可能干扰。

进MySQL执行：SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';，若返回0或空值，说明自动清理关闭
同时查SHOW VARIABLES LIKE 'expire_logs_days';，若非0，必须立刻SET GLOBAL expire_logs_days = 0;清掉，避免冲突
注意：仅SET GLOBAL是临时的，重启即失效；必须编辑my.cnf（如宝塔路径是/www/server/mysql/etc/my.cnf），在[mysqld]段追加：

binlog_expire_logs_seconds = 604800
expire_logs_days = 0

然后systemctl restart mysqld，重启后立刻验证变量值是否已更新。

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

直接PURGE MASTER LOGS TO 'mysql-bin.000036';可能断主从——删掉从库还没读的日志，Slave_IO_Running立刻变No，报错Got fatal error 1236。

主库上执行SHOW MASTER STATUS;，记下当前File（比如mysql-bin.000042）
所有从库连上去执行SHOW SLAVE STATUS\G，重点看Relay_Master_Log_File和Exec_Master_Log_Pos
找出所有从库中Relay_Master_Log_File最旧的那个（比如mysql-bin.000035），这就是安全下限：你最多只能PURGE TO 'mysql-bin.000036';
执行命令：PURGE BINARY LOGS TO 'mysql-bin.000036';，清理后SHOW BINARY LOGS;确认数量下降

Linux下即使PURGE成功，如果还有进程（比如慢查询、长事务、未关闭连接）正持有旧binlog的文件句柄，磁盘空间就不会真正释放。

运行lsof +L1，看是否有deleted状态的mysql-bin.*文件被进程占用
若有，对应PID通常是MySQL自身（mysqld），此时需确认是否有大事务卡住：SELECT * FROM information_schema.INNODB_TRX ORDER BY TRX_STARTED LIMIT 5;
紧急情况下可杀掉长期运行事务：KILL [trx_mysql_thread_id];，但务必先确认业务影响
更稳妥做法是等事务自然结束，或重启MySQL（生产环境慎用）

真正的难点不在命令怎么写，而在于你得同时盯住主库位置、所有从库同步点、以及有没有隐藏的大事务死锁着句柄——三者缺一，清理就白做。