必须显式配置log_bin且路径可写，否则MySQL启动失败或静默禁用Binlog；需确保目录存在、属主正确、权限充足，并配套设置server-id和binlog_format=ROW。
log_bin 必须显式配置且路径可写，否则 MySQL 启动失败或静默禁用 Binlog —— 这是绝大多数“明明配了却查不到 log_bin=ON”的根本原因。
确认 MySQL 是否具备 Binlog 写入权限
Binlog 不是“配了就生效”，它依赖 MySQL 进程对指定目录的写权限。常见错误现象：show variables like '%log_bin%'; 返回 OFF，但配置文件里明明写了 log_bin=/data/mysql/binlog/mysql-bin。
- 检查路径父目录是否存在：
/data/mysql/binlog/必须提前创建，MySQL 不会自动建多级目录 - 确认属主属组：该目录需属于
mysql用户（如使用 systemd 启动，通常为mysql:mysql） - 验证写权限：
sudo -u mysql touch /data/mysql/binlog/test.tmp && rm /data/mysql/binlog/test.tmp - 若使用 SELinux 或 AppArmor，需额外放行日志路径（例如 RHEL/CentOS 上运行
sudo semanage fcontext -a -t mysqld_db_t "/data/mysql/binlog(/.*)?"并restorecon -Rv /data/mysql/binlog）
log_bin 与 log_bin_basename 的区别必须分清
这两个参数常被混用，但行为完全不同：
-
log_bin=/var/lib/mysql/mysql-bin：启用 Binlog 并指定基础路径+前缀；生成的文件是mysql-bin.000001、mysql-bin.000002等 -
log_bin_basename=/var/lib/mysql/mysql-bin：仅设置路径前缀，**不启用 Binlog**；必须同时存在log_bin才有效 - 若只写
log_bin_basename而漏掉log_bin，MySQL 完全忽略该配置，log_bin变量仍为OFF - 建议始终使用
log_bin，避免引入log_bin_basename这个冗余变量
必须配套设置 server-id，否则主从复制会失败
即使你当前只用 Binlog 做恢复，不搭从库，也建议设 server-id。原因很实际：
- MySQL 5.7+ 默认启用
enforce_gtid_consistency=ON或 GTID 模式时，server-id是强制要求 -
SHOW MASTER STATUS在未设server-id时可能返回空结果，导致mysqlbinlog解析或备份脚本出错 - 值必须是正整数（不能为 0），且在同集群中全局唯一；单机测试可设为
1 - 配置示例（追加到
[mysqld]段）：log_bin = /var/lib/mysql/mysql-bin<br>server-id = 1
binlog_format 别用默认值赌运气
MySQL 8.0 默认是 ROW，但很多旧环境仍是 MIXED 或 STATEMENT。生产环境应显式声明：
-
STATEMENT：记录原始 SQL，体积小，但遇到NOW()、UUID()、自定义函数等非确定性操作时，主从数据可能不一致 -
ROW：记录每行变更前后的镜像，体积大但一致性高；mysqlbinlog输出更易读（带# at 123和### UPDATE ...） -
MIXED：自动降级为 ROW 的场景有限（如含函数的 UPDATE），不如直接设ROW来得可控 - 强烈建议设为
binlog_format = ROW，并搭配log_bin_trust_function_creators = ON（若用自定义函数）
log_bin 配置生效后，MySQL 会立即生成第一个日志文件（如 mysql-bin.000001）和索引文件（mysql-bin.index）。这两者缺一不可——索引文件损坏或缺失会导致 SHOW BINARY LOGS 报错或返回空，后续所有基于 Binlog 的操作都会卡住。运维时别只盯着日志文件，定期 ls -l 看一眼索引文件是否存在、是否被意外清空。
