relay log是从库本地存储主库binlog事件的完全一致副本，用于解耦接收与执行；它不解析改写，可被mysqlbinlog直接解析；其存在保障网络中断、主库日志清理或从库重启后的可靠同步。
relay log 是从库的“本地 binlog 缓冲区”
relay log 不是独立设计的日志格式，它和主库的 binlog 完全一致——同样的事件结构、同样的文件编号规则、同样的索引机制。它的存在意义只有一个：把主库发来的 binlog 事件，先落盘到从库本地，再由 SQL thread 顺序读取执行。这样就解耦了“接收”和“执行”两个动作。
常见误解是把它当成某种“中间转换日志”，其实它不解析、不改写、不压缩，就是原样存储。你可以用 mysqlbinlog 直接解析 mysql-relay-bin.000001，看到的 event 内容和主库上对应 mysql-bin.000001 的那部分完全一样。
为什么不能直接让 SQL thread 拉取主库 binlog？
因为网络不可靠、主库 binlog 可能被自动清理、从库重启后需要断点续传——这些都要求从库必须有自己可控的、持久化的日志副本。
-
relay_log_purge=ON（默认）时，SQL thread 执行完某段 relay log 后，该文件会被自动删除；但只要没执行完，哪怕主库的对应binlog已被expire_logs_days清掉，从库仍能继续同步 - 如果 I/O thread 因网络中断暂停，已写入的 relay log 保留着未拉取的部分，恢复连接后从中断位置继续，而不是重头开始
- 启用
relay_log_recovery=ON（推荐），能在从库异常宕机后跳过损坏的 relay log，自动从relay_log_info_file记录的位置重建中继日志，避免手动干预
查看和定位 relay log 的关键路径与状态
所有 relay log 文件默认放在 datadir 下，命名格式为 host_name-relay-bin.xxxxxx，配套的索引文件是 host_name-relay-bin.index。实际路径受以下变量控制：
-
relay_log：可显式指定文件前缀，比如设为/data/mysql/relay-bin，则生成/data/mysql/relay-bin.000001 -
relay_log_index：默认跟relay_log同目录同前缀，但可单独配置，如/data/mysql/relay-bin.index -
relay_log_info_file：记录当前 SQL thread 执行到哪个 relay log 的哪个 position，例如relay-log.info，内容类似：./mysql-relay-bin.000005 123456789
运行 SHOW SLAVE STATUS\G 时，Relay_Log_File 和 Relay_Log_Pos 就来自这个文件；而 Master_Log_File/Read_Master_Log_Pos 来自 I/O thread 当前读到的主库 binlog 位置。
relay log 大小和轮转容易被忽略的细节
max_relay_log_size 控制单个 relay log 文件最大字节数，默认为 0，此时继承 max_binlog_size（通常 1GB）。但它只影响新创建的文件，不会触发已有大文件的切割。
真正决定何时轮转 relay log 的，是 I/O thread 拉取到的 binlog event 是否跨了主库的 binlog 文件边界。例如主库 mysql-bin.000003 最后一个 event 被写入当前 relay log，下一个 event 来自 mysql-bin.000004，那么 I/O thread 就会主动 rotate 当前 relay log 并新建下一个——这个行为不受 max_relay_log_size 约束。
所以如果你发现 relay log 文件远大于 1GB，不是配置失效，而是主库 binlog 切得不够勤，或者正在写一个超大事务的 events。
