在MySQL的master-slave或dual master的架构中，我们经常使用show slave status命令来查看复制状态。

这里涉及几个重要的日志文件和位置：

• Master_Log_File，Read_Master_Log_Pos: 记录了IO thread读到的当前master binlog文件和位置，对应master的binlog文件和位置。
• Relay_Log_File，Relay_Log_Pos: 记录了SQL thread执行到relay log的那个文件和位置，对应的是slave上的relay log文件和位置。
• Relay_Master_Log_File，Exec_Master_Log_Pos: 记录的是SQL thread执行到master binlog的文件和位置，对应的master上binlog的文件和位置。

binlog的event语句开始位置就是二进制binlog文件的字节偏移位置。而且根据上一个event的end_log_pos可以找到下一个event开始的位置，如下图所示。

下图是一个mysqlbinlog解析普通的relay log文件出来的文本文件：

relay log和binlog记录方式基本相同，最大的不同就是end_log_pos记录的是master的binlog文件中event的位置，而不是relay log自己event的位置。如图所示，上一个event的end_log_pos和下一个relay log event开始的位置不一样。为什么需要这样设置？就是为了方便找到master binlog的位置。在slave上，记录relay log 下一个event的开始偏移意义不大，但是如果记录了master binlog的偏移量，我们就可以在SQL thread中明确我们执行到master的某个binlog的哪个位置了。每个relay log开头都有这么一个rotate event，也就是当前master的binlog文件名。

• IO thread 把所有从master读到的binlog记录到本地的binlog中，所以relay log的最后一个event的end log_pos就是Read_Master_Log_Pos
• SQL thread 按照transaction来执行，所以Exec_Master_Log_Pos对应relay log中最后一个事务event的end_log_pos，这个位置对应的是master的binlog的位置。
• Relay_Log_Pos 记录的是SQL thread执行的event在relay log中结束位置，这个才是relay log的偏移量。

MySQL的slave端是通过2个线程实现复制的，一个是I/O Thread负责连接到master接收binlog信息，在从服务器端这部分信息叫做relay log。另一个SQL Thread负责读取relay log并执行其中的event（在statement format的时候其实就是SQL语句）。当遇到一些I/O Thread或SQL Thread的报错时，我们可以通过change master to命令修改连接参数和复制起始点，其中重要的MASTER_LOG_FILE和MASTER_LOG_POS参数，这两个参数对应的是IO线程生成relay log的信息，因此和Relay_Master_Log_File和Exec_Master_Log_Pos是对应的。