relay log是MySQL主从复制中从库接收并暂存主库binlog事件的中转日志，由I/O线程写入、SQL线程读取执行，实现数据同步。

MySQL 使用 relay log 主要是在 复制（replication） 环境中，由从库（slave）使用。relay log 并不是手动直接操作的日志文件，而是由 MySQL 复制机制自动管理的。它的作用是记录从主库接收到的二进制日志（binary log）事件，并在从库上重放这些事件以实现数据同步。

relay log 的工作原理

在 MySQL 主从复制中：

• 从库的 I/O 线程连接到主库，请求主库的 binlog 更新。
• 主库将 binlog 事件发送给从库，从库的 I/O 线程接收到后，写入本地的 relay log 文件。
• 从库的 SQL 线程读取 relay log 中的内容，按顺序执行其中的 SQL 语句或事务，从而保持与主库的数据一致。

relay log 就像一个“中转站”，把主库的变更先暂存下来，再逐步应用。

relay log 的文件结构和位置

relay log 文件通常位于 MySQL 的数据目录下，默认命名格式为：

hostname-relay-bin.000001

还有一个索引文件记录所有 relay log 文件名：

如知AI笔记

如知笔记——支持markdown的在线笔记，支持ai智能写作、AI搜索，支持DeepseekR1满血大模型

27

查看详情

hostname-relay-bin.index

可以通过以下命令查看当前 relay log 的状态：

<strong>SHOW SLAVE STATUSG</strong>

关注字段如：

• Relay_Log_File：当前正在使用的 relay log 文件名。
• Relay_Log_Pos：当前已读取到的位置。
• Relay_Master_Log_File：对应的主库 binlog 文件。

如何管理和维护 relay log

正常情况下不需要手动干预 relay log，但某些场景下可以进行管理：

• 清除旧的 relay log：
  使用 RESET SLAVE 或 RESET SLAVE ALL 可删除所有 relay log 并重置复制信息（注意：这会清除复制配置，慎用）。
• 跳过错误并继续复制：
  如果 SQL 线程因某条语句出错而停止，可设置 sql_slave_skip_counter 跳过指定数量的事件（适用于非 GTID 模式）。
• 启用 GTID 后更安全地管理 relay log：
  GTID 模式下，MySQL 能自动定位同步位置，减少对 relay log 手动处理的需求。

常见相关参数配置

可以在 my.cnf 中配置 relay log 行为：

• relay_log = /path/to/relay-bin：自定义 relay log 文件路径和前缀。
• relay_log_purge = 1：启用自动清理已应用的 relay log（默认开启）。
• relay_log_recovery = 1：崩溃恢复时自动重建 relay log，保证一致性（建议开启）。

基本上就这些。relay log 是 MySQL 复制的核心组件之一，理解它有助于排查复制延迟、中断等问题。只要复制正常运行，你不需要手动读写 relay log 文件，MySQL 会自动处理。不复杂但容易忽略。