mysql二进制日志必须通过修改配置文件启用，log-bin和server-id为硬性必需项；需在[mysqld]段下正确配置路径与唯一id，设binlog-format=row，用binlog_expire_logs_seconds或expire_logs_days清理，重启后以show variables like 'log_bin'和show master status验证生效。
MySQL二进制日志（binlog）在Linux上必须通过修改配置文件启用，不能仅靠SQL命令动态开启；log-bin和server-id是两个硬性必需项，缺一不可。
确认配置文件位置并编辑[mysqld]段落
不同发行版或MySQL版本的配置文件路径不统一，常见位置有：/etc/my.cnf、/etc/mysql/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf。先用命令定位：
find /etc -name "my.cnf" 2>/dev/null find /etc -name "mysqld.cnf" 2>/dev/null
找到后，在[mysqld]节下添加或修改以下内容：
-
log-bin = /var/lib/mysql/binlog/mysql-bin：路径需存在且MySQL用户（通常是mysql）有写权限；若只写log-bin = mysql-bin，日志将落在数据目录（datadir）下 -
server-id = 1：必须是非0整数，单机可设为1；主从环境中每个节点必须唯一 - 确保没有拼写错误，比如
log_bin（带下划线）是无效的，正确写法是log-bin（带连字符）
选择binlog-format并避免STATEMENT陷阱
binlog-format = ROW是当前生产环境事实标准，尤其涉及函数、触发器、临时表或非确定性SQL时，STATEMENT极易导致主从数据不一致。
-
ROW：记录每行变更细节，安全但体积大；适用于所有复制场景 -
MIXED：自动降级为ROW处理高风险语句，兼容性好，但行为不易预测 -
STATEMENT：已不推荐；NOW()、UUID()、LOAD_FILE()等函数在主从上执行结果可能不同 - 注意：MySQL 8.0.26+默认格式已是
ROW，但显式声明仍有必要，避免被旧配置覆盖
设置清理策略防止磁盘爆满
binlog不自动清理，长期运行后可能占满磁盘。优先使用binlog_expire_logs_seconds（MySQL 8.0.28+），兼容性更好：
-
binlog_expire_logs_seconds = 2592000（30天），比expire_logs_days更精确，且不受时区影响 - 若版本较老，用
expire_logs_days = 7，但注意该参数单位是“天”，不是“小时”或“秒” -
max_binlog_size = 1G控制单个文件大小，但实际切换还受事务边界影响——一个大事务不会被截断 - 切勿依赖
rm -f /var/lib/mysql/binlog/*手动删除，必须用PURGE BINARY LOGS或让MySQL自动管理，否则mysql-bin.index会损坏
重启后验证log_bin是否真正生效
重启服务后，登录MySQL执行：
SHOW VARIABLES LIKE 'log_bin';
返回ON才表示成功；如果仍是OFF，常见原因有：
- 配置写在了
[client]或[mysql]段，而非[mysqld] - MySQL启动时读取了多个配置文件，被后面加载的文件覆盖（可用
mysqld --verbose --help | grep "Default options"确认加载顺序） -
log-bin路径所在目录不存在，或mysql用户无写权限（检查ls -ld /var/lib/mysql/binlog及父目录） - MySQL error log里有明确报错，例如
Could not open log file，务必查error.log定位
最后跑一次SHOW MASTER STATUS;，有输出说明binlog已开始写入——这才是最终确认点。
