MySQL主从复制从库拉取日志机制是否与主库推送数据理论矛盾

首先需要明确：通用数据库理论中定义的「主从复制（Master-Slave Replication）」从来没有把“主库主动推送数据”作为强制判定标准，其核心判定规则只有三点：

• 主节点（Master/Source）是数据写入的唯一可信来源，所有数据变更首先在主节点落地
• 从节点（Replica/Slave）默认不接收业务侧独立写入（忽略手动改从库、读写分离只读场景的例外情况），自身数据状态需要和主节点保持最终一致
• 数据变更流向为单向，只会从主节点同步到从节点，不会出现反向同步

大家印象里的“主库主动推送数据到从库”只是部分数据库产品选择的实现路径，不是主从复制的硬性准入规则。

DigitalOcean社区的MySQL复制配置教程中对MySQL复制线程的描述是准确的：

replica实例完成初始化后，会创建两个线程进程：第一个为IO thread，负责连接source MySQL实例，逐行读取binary log事件，将其复制到replica服务器本地名为relay log的文件中；第二个为SQL thread，负责从relay log读取事件，尽快在replica实例上重放执行对应操作。

MySQL选择从库主动拉取（Pull）binlog的模式，完全是出于性能和稳定性的工程考量：

• 如果采用主库主动推送（Push）模式，主库需要维护所有从库的连接状态、同步位点、重试逻辑、流控策略，当从库数量较多、从库负载高追不上数据、网络出现波动时，这些同步逻辑会额外占用主库的CPU、内存、网络资源，直接影响主库承载业务写入的核心能力
• 把拉取主动权交给从库后，主库只需要在收到从库的连接请求时，启动一个对应的binlog dump线程，按从库上报的同步位点返回对应binlog事件即可，不需要关心从库的重放进度、重连逻辑，职责非常轻量；从库可以根据自身的负载情况、网络状态自主控制拉取速度，不会因为自身性能问题反过来拖垮主库
• 从数据流向看，同步的内容依然是主库生成的原生binlog变更事件，主库依然是唯一的可信数据源，完全符合主从复制的核心逻辑，和“主库推送”模式的区别仅仅是传输请求的发起方不同而已。

实际上行业内主流数据库的主从实现本来就没有统一的传输模式：除了MySQL的从库拉取模式，也有不少数据库选择主库推送模式，两种模式没有高低之分，都是适配自身产品架构的选型，不存在谁违背主从复制理论的说法。

内容的提问来源于stack exchange，提问作者Palak Jain