从库未开启binlog会导致主从切换失败、增量恢复能力丧失及mysqldump备份失败；需配置log_bin、唯一server_id和server_uuid，必要时启用log_slave_updates以支持pitr和级联复制。
从库没开 binlog 会导致主从切换失败
MySQL 从库默认 log_bin 是关闭的，这在纯读写分离场景下没问题；但一旦你要用它做故障切换（比如主挂了，把从库提升为主），立刻卡住——因为新主库必须能生成 binlog，否则后续从库无法继续同步。
更隐蔽的问题是：某些高可用工具（如 MHA、Orchestrator）依赖从库的 Exec_Master_Log_Pos 和本地 binlog 位置做一致性校验，没开 binlog 就拿不到 Relay_Log_File 对应的本地事件，直接拒绝提升。
- 开启方式很简单：
log_bin = /var/lib/mysql/mysql-bin（路径需存在且 MySQL 有写权限） - 必须同时设置
server_id（不能和主库重复），否则启动报错ERROR 1592 (HY000): Binary logging not possible - 无需开
log_slave_updates——除非你打算让这个从库再挂下级从库（比如级联复制）
备份节点不开 binlog 会丢增量恢复能力
如果你把从库当冷备/归档节点，只定期 mysqldump 或 xtrabackup，那关 binlog 看似省 IO；但真出事时，你会发现只能恢复到上次备份时间点，中间所有变更全丢了。而开了 binlog 后，可以用 mysqlbinlog 拿到完整增量日志，实现 PITR（Point-in-Time Recovery）。
- 备份策略要配套调整：除了全量备份，还得定期拉取并归档从库的 binlog（比如用
mysqlbinlog --read-from-remote-server） - 注意
expire_logs_days要设得比备份周期长，否则 binlog 被自动清理，增量链就断了 - 如果磁盘紧张，可以关
binlog_format = ROW改成STATEMENT（但需确认业务无不安全语句），不过现在 SSD 普及，优先保安全
开启 binlog 对从库性能影响其实很小
很多人怕开 binlog 拖慢从库，实际测试中，只要不是极端写密集型场景（比如每秒上万事务），写 binlog 的开销几乎不可见。真正影响性能的是 sync_binlog 和 innodb_flush_log_at_trx_commit 的组合。
- 生产环境建议设
sync_binlog = 1（保证 crash-safe），但别碰innodb_flush_log_at_trx_commit = 2——这会让 InnoDB 日志刷盘异步，反而破坏一致性 - 避免设
sync_binlog = 0：虽然性能略好，但 MySQL 崩溃后 binlog 可能比 InnoDB 数据多，导致主从数据不一致 - 从库写 binlog 不走 relay log 解析重放路径，是直接记录 SQL 线程执行后的结果，所以延迟不会因此增加
mysqldump 备份时加 --master-data=2 依赖从库 binlog 开启
这个参数本意是让 dump 文件里带 CHANGE MASTER TO 语句，方便快速搭新从库。但它实际读的是从库当前的 SHOW MASTER STATUS 输出——如果 log_bin 关着，这条命令直接报错 ERROR 1381 (HY000): You are not using binary logging，dump 就失败。
- 不用
--master-data也能备份，但后续搭建从库得手动找位点，容易错 - 如果从库 binlog 开了但
log_slave_updates关着，SHOW MASTER STATUS返回的是空位点（File='', Position=0），--master-data=2仍会失败 - 稳妥做法：开
log_bin+ 开log_slave_updates（仅当需要做级联或 PITR 时才必须）
最常被忽略的一点：从库开启 binlog 后，server_uuid 必须唯一。如果用克隆镜像部署多个从库，没改 /var/lib/mysql/auto.cnf，重启后所有实例 UUID 相同，主从复制会静默中断，错误日志里只有一行 Got fatal error 1236 from master，查半天才发现是 UUID 冲突。
