binlog 在主库上必须启用且格式要选对
MySQL 主从复制依赖主库的
binlog记录写操作，如果主库没开
binlog，从库根本收不到任何变更。确认方式是执行
SHOW VARIABLES LIKE 'log_bin';，返回
ON才算启用。
更关键的是
binlog_format的取值：推荐用
ROW，它记录每一行数据的实际变化，能准确还原 DML 操作，避免
STATEMENT在函数、临时表、非确定性语句下产生主从不一致。但注意：
ROW日志体积更大，尤其大批量
UPDATE或
DELETE时会显著增加磁盘压力。
SET GLOBAL binlog_format = 'ROW';只影响新会话，需写入配置文件永久生效 配置项应加在
[mysqld]段下：
log-bin = mysql-bin<br>binlog-format = ROW<br>server-id = 1修改后必须重启 MySQL，
log-bin路径不能是相对路径，否则启动失败
relay log 不可手动删除，靠 SQL 线程自动清理
从库收到的 binlog 事件先写入
relay log，再由
SQL Thread重放。这些文件默认以
hostname-relay-bin.xxxxxx命名，位置由
relay_log配置项决定（未显式设置时用主机名 +
-relay-bin）。
常见误区是像清理 binlog 那样用
PURGE RELAY LOGS或直接删文件——这极易导致从库中断。正确做法是让
SQL Thread自动管理：它重放完一个 relay log 文件后，会自动删除（前提是
relay_log_purge = ON，这是默认值）。 手动触发清理仅限紧急场景：
PURGE RELAY LOGS BEFORE 'mysql-relay-bin.000010';执行前务必确认
SHOW SLAVE STATUS\G中
Relay_Master_Log_File和
Exec_Master_Log_Pos已越过目标文件 若误删正在使用的 relay log，从库会报错
Could not parse relay log event entry，只能重做从库
binlog 过期时间与 relay log 空间需分开控制
expire_logs_days控制主库 binlog 保留天数，但不影响从库 relay log；而
relay_log_space_limit是从库上唯一能限制 relay log 总磁盘用量的参数（默认为 0，即不限制）。这两个值必须根据实际流量和运维节奏配平。 主库写入频繁时，
expire_logs_days = 7可能不够，建议结合
max_binlog_size（如
100M）防止单个文件过大 从库若延迟严重，
relay_log_space_limit设太小会导致 IO 线程停写，报错
The relay log space quota has been exceeded监控重点不是文件数量，而是
SHOW SLAVE STATUS中的
Seconds_Behind_Master和磁盘剩余空间
GTID 开启后 binlog 和 relay log 行为有隐式约束
启用 GTID（
gtid_mode = ON+
enforce_gtid_consistency = ON）后，MySQL 会强制所有事务带全局唯一标识，此时
binlog和
relay log的内容结构、校验逻辑都发生变化：比如
SQL Thread不再依赖 position，而是按
GTID_SET顺序执行；
PURGE BINARY LOGS也不能按时间或文件名删，必须用
PURGE BINARY LOGS TO 'mysql-bin.000015';且目标文件必须是已执行过的最小 binlog。 GTID 模式下，从库
relay_log_recovery = ON必须开启，否则重启后可能找不到正确的 relay log 起始点 切换 GTID 前必须确保主从所有节点 binlog 完整、无损坏，否则
gtid_purged设置错误会导致复制断裂 不要混用
CHANGE MASTER TO ... MASTER_LOG_FILE和 GTID，会直接报错
Cannot CHANGE MASTER when @@GLOBAL.GTID_MODE = ONbinlog 和 relay log 看似只是日志文件，但它们的生命周期、权限归属、清理边界全由不同线程和配置项交叉控制。最常出问题的地方不在“怎么开”，而在“什么时候不该删”和“哪个配置项实际生效”。
