MySQL主从库复制中，主库如何查找对应日志文件位置
在基于 GTID 的复制中，从库发送已执行的 GTID 集合后，主库查找对应日志文件位置的过程，本质上是一个 “智能计算” 而非简单的“文件指针跳转”。
这个过程的核心，就是主库利用二进制日志中特殊标记（Previous_gtids_log_event）的索引功能，快速定位到从库缺失事务的起始点。
⚙️ 主库的“三步定位法”
整个过程可以分解为以下几个关键步骤：
- 计算差集：明确“缺什么”
主库收到从库的 gtid_executed 集合后，会与自己当前的 gtid_executed 集合进行对比，计算出差集。这个差集就是“从库已经执行过的事务”（Slave_GTIDs）和“主库上发生过的事务”（Master_GTIDs）之间的差异。
· 场景示例：假设主库 GTID 集合为 1-100，从库发来的集合为 1-90，那么差集就是 91-100。 - 扫描文件：定位“在哪儿找”
这是最关键的一步。主库需要知道包含事务 91 的二进制日志文件是哪一个。为此，它会从最早的二进制日志文件开始，依次读取每个文件开头的特殊事件——Previous_gtids_log_event。
· Previous_gtids_log_event 的作用：在每个二进制日志文件的开头，都记录了一个重要信息：“本文件之前所有已执行事务的 GTID 集合”。这就像是给每个文件贴了一个“内容标签”。
· 快速定位：主库读取第一个文件的 Previous_gtids_log_event，比如内容是 1-50。因为从库需要的 91 明显大于 50，说明目标事务不在此文件中，主库会跳过该文件。接着检查第二个文件，其 Previous_gtids_log_event 为 1-80，91 仍然不在其中，继续跳过。直到检查到第三个文件，其 Previous_gtids_log_event 为 1-90。主库发现，事务 91 并不包含在“本文件之前”的集合中，因此可以断定：事务 91 就从这个文件开始。 - 验证完整性：确保“都能给”
在开始发送数据前，主库还有一个重要的安全校验：它会检查自己是否还完整地保留着从库所需要的所有 binlog 文件。
· 如果所需的 binlog 文件（例如包含事务 91 的那个文件）因为过期已经被清理或删除，主库将无法提供完整的数据。这时，主库不会开始复制，而是直接向从库返回一个错误，提示所需的 binlog 已被清理。
· 如果文件都存在，则校验通过，进入下一步。 - 逐事件扫描：找到“起始点”
在确定了包含事务 91 的二进制日志文件后，主库会顺序读取该文件中的每个事件，逐一检查每个 Gtid_log_event。这个过程会一直持续，直到找到第一个不属于从库 gtid_executed 集合的事务，也就是事务 91 对应的 Gtid_log_event。 - 开始传输：从“起始点”推送
一旦定位到事务 91 的 Gtid_log_event，主库就找到了复制的精确起点。从这个事件开始，主库会将该事务以及之后的所有事务（92、93……）顺序打包，通过 COM_BINLOG_DUMP_GTID 协议推送给从库。
💡 核心差异总结
这个过程和传统基于位点的复制有着本质区别：
· 传统位点复制：运维人员需要手动指定 MASTER_LOG_FILE 和 MASTER_LOG_POS。主库只是机械地听从指令，从指定位置开始发送，并不关心这个位置是否正确或完整。
· GTID 自动定位：从库告诉主库“我有什么”，主库自己计算“你需要什么”，并通过内置的“索引”（Previous_gtids_log_event）智能地找到从哪里开始提供。整个过程自动、精确且安全。