如何开启与配置Binlog日志_log_bin参数与日志格式选择

执行 SHOW VARIABLES LIKE ‘log_bin’; 返回 ON 才表示 Binlog 真正启用；若为 OFF，需检查错误日志权限或路径问题，且 log_bin 为只读变量，必须重启生效。

如何确认 log_bin 是否已启用

MySQL 启动时是否开启 Binlog，不看配置文件有没有写 log_bin，而要看实际运行状态。很多用户改了 my.cnf 却没重启 MySQL，或者写错了路径导致启动失败回退到默认配置。

• 直接执行 SHOW VARIABLES LIKE 'log_bin'; —— 返回 ON 才算真正生效
• 如果返回 OFF，检查错误日志（通常是 /var/log/mysql/error.log 或 mysqld.err），常见报错是 File '/var/lib/mysql/mysql-bin.index' not found (Errcode: 13 - Permission denied)，说明目录权限不对或路径不可写
• log_bin 是只读变量，运行时不能用 SET GLOBAL log_bin = ON 修改，必须重启 mysqld

log_bin 的路径和文件名怎么设才安全

不建议只写 log_bin = ON（MySQL 5.7+ 允许但隐式生成默认路径），因为默认会把日志写进数据目录，和 ibdata1 混在一起，既影响备份隔离，又可能因磁盘满导致主库宕机。

• 显式指定路径：例如 log_bin = /data/mysql/binlog/mysql-bin，注意末尾不带扩展名，MySQL 会自动加 .000001 等序号
• 确保 /data/mysql/binlog/ 目录存在、属主为 mysql 用户、有读写权限（chown mysql:mysql /data/mysql/binlog && chmod 750 /data/mysql/binlog）
• 避免使用 NFS 或低 IOPS 的网络存储——Binlog 是顺序写密集型，挂载点延迟高会导致主库 commit 变慢

选 ROW 还是 STATEMENT 格式？关键看业务写法

格式由 binlog_format 控制，不是“越详细越好”。ROW 虽然精确，但日志体积大、解析慢；STATEMENT 节省空间，但遇到 NOW()、UUID()、自增主键等非确定性函数会出问题。

• 只要用了 INSERT …… SELECT、触发器、存储过程、或任何含函数的写操作，一律用 ROW
• 纯简单 CRUD 且无时间 / 随机函数，STATEMENT 在从库重放更快，但现实中极少满足这个条件
• MIXED 是折中方案，但 MySQL 实际判断逻辑黑盒多，线上环境不如明确锁死为 ROW 省心
• 修改后需重启或执行 SET GLOBAL binlog_format = 'ROW';（仅对新连接生效，已有连接保持旧值）

为什么 expire_logs_days 不起作用？

这个参数在 MySQL 8.0 已废弃，换成 binlog_expire_logs_seconds。即使版本够老，它也只控制“自动清理”，不阻止日志写满磁盘。

• MySQL 5.7：设 expire_logs_days = 7，但若磁盘空间不足，binlog 仍会写失败并卡住所有写入
• MySQL 8.0+：必须用 binlog_expire_logs_seconds = 604800（7 天），且需配合 binlog_space_limit（如 10G）做双重防护
• 更稳妥的做法是外置定时任务：每天跑 mysql -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);"，并监控 SHOW BINARY LOGS; 的文件数量与总大小

Binlog 配置最易被忽略的，是日志路径的磁盘容量和权限隔离——它不像慢查询日志那样允许“写失败就丢弃”，一旦出问题，整个主库写入就停摆。