主库必须启用binlog且设为ROW格式，从库relay log不可手动删除，GTID模式下需严格遵循清理和配置规则。

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
  binlog-format = ROW
  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 = ON