必须同时配置log-bin和server-id，否则binlog无法启用；log-bin需绝对路径且目录可写，server-id须为非零唯一整数，配置后必须重启MySQL并验证文件生成与SHOW MASTER STATUS输出。
必须配置 log-bin 和 server-id，否则二进制日志无法启用，后续所有恢复操作都无从谈起。
log-bin 路径必须是绝对路径且目录可写
MySQL 启动时会尝试在指定路径下创建 mysql-bin.000001 及 mysql-bin.index。如果路径不存在、权限不足或磁盘满，log-bin 会静默失效（show variables like 'log_bin' 仍显示 ON，但实际不写日志）。
- 检查路径是否存在：
ls -ld /data/mysql/binlog，若无则mkdir -p /data/mysql/binlog && chown mysql:mysql /data/mysql/binlog - 避免与数据目录共用同一块物理盘——万一磁盘损坏，binlog 就丢了
- 不要写成
log-bin = mysql-bin（相对路径），这会让 MySQL 写到数据目录下，且容易被误删
server-id 必须是非零整数，且集群中唯一
server-id 不只是主从复制才需要。即使单机做恢复，mysqlbinlog 解析时也依赖该值判断事件来源；某些版本（如 MySQL 8.0.23+）在 binlog_format = ROW 下若 server-id = 0，会拒绝写入 binlog。
- 设为
server-id = 1是安全起点，但生产环境建议用有意义的数字（如 IP 尾号或实例 ID） - 不能设为
0或空值；也不能和集群内其他实例重复，否则主从同步会报错Got fatal error 1236 - 修改后必须重启 MySQL，
SET GLOBAL server_id = 1不生效
配置后必须验证是否真实写入
改完 /etc/my.cnf 并重启，不代表 binlog 就在工作。常见假成功：配置语法正确、MySQL 启动成功、log_bin 变量显示 ON，但文件一个都没生成。
- 执行
SHOW BINARY LOGS;—— 若报错ERROR 1381 (HY000): You are not using binary logging，说明没生效 - 执行
SHOW MASTER STATUS;—— 正常应返回非空File和Position，如mysql-bin.000001和154 - 手动触发一次写操作：
CREATE TABLE t(id INT); INSERT INTO t VALUES(1);，再查ls -l /data/mysql/binlog/mysql-bin.*，文件大小应 > 0
最容易被忽略的是：配置了 log-bin 却没配 server-id，或配了但值为 0。这种情况下 MySQL 不报错，但 binlog 文件永远为空，等真出事才发现日志根本没记——恢复就只剩全量备份一条路了。
