在现代互联网架构中，MySQL主复制原理不仅是数据库高可用（High Availability）的核心基础，更是读写分离、数据备份、灾难恢复等高级架构设计的先决条件。无论是初创团队还是大型分布式系统，深入理解主从复制的底层机制，对于解决数据一致性、同步延迟以及故障切换等问题至关重要。
基于Binlog日志的异步、半同步或组复制机制，实现数据在主从节点间的可靠传递。
从传统的基于File/Position的复制，进化到基于GTID的自动化复制，再到MGR组复制。
探讨如何平衡性能与一致性，解决主从数据不一致的常见陷阱与解决方案。
理解MySQL主复制原理，关键在于掌握主库（Master）与从库（Slave/Replica）之间三个核心线程的协作。整个过程可以概括为：主库写日志、从库传日志、从库重放日志。
当主库接收到客户端的写请求（如INSERT, UPDATE, DELETE）并执行成功后，会将这些操作记录到二进制日志（Binary Log, Binlog）中。与此同时，主库会启动一个Binlog Dump Thread，专门负责向从库推送Binlog内容。注意，只有当从库连接上来时，该线程才会工作。
从库启动后，会创建一个I/O Thread，主动连接主库的Binlog Dump Thread。主库根据从库请求的日志位置和GTID信息，将对应的Binlog数据发送给从库的I/O线程。I/O线程接收到数据后，不会立即执行，而是将其保存到本地的中继日志（Relay Log）中。
这是复制性能瓶颈的关键所在。SQL Thread负责读取本地的Relay Log，并将其中的事件（Event）重放（Replay）到从库数据库中。在MySQL 5.6之前，SQL线程是单线程的，这意味着如果主库并发写入量大，从库很容易出现延迟。MySQL 5.6引入了并行复制（Parallel Replication），允许SQL线程多线程执行，大幅提升了复制效率。
| 线程名称 | 所在节点 | 主要职责 | 关键文件/状态 |
|---|---|---|---|
| Binlog Dump Thread | Master | 读取Binlog并推送给Slave | Binlog File |
| I/O Thread | Slave | 拉取Master Binlog并写入本地Relay Log | Relay Log, Master_Log_File |
| SQL Thread | Slave | 读取Relay Log并执行SQL | Relay Log, Exec_Master_Log_Pos |
不同的业务场景对数据一致性和性能的要求不同，MySQL提供了多种主复制原理的实现模式。以下是三种主流模式的深度对比：
这是MySQL默认的复制模式。主库执行完事务后，不等待从库的确认，直接返回成功给客户端。
主库执行完事务后，至少等待一个从库将数据写入Relay Log并反馈ACK，才返回成功。若超时未收到反馈，则降级为异步复制。
基于Paxos协议的分布式共识算法，实现多主或单主模式的组复制。所有节点数据强一致，任意节点可读写。
在实际生产环境中，MySQL主复制原理落地时，最头疼的问题往往是主从延迟（Replication Lag）和数据不一致。以下是针对这些痛点的深度分析与解决方案。
延迟的本质是从库SQL线程执行速度赶不上主库Binlog生成速度。常见原因包括：
针对MySQL主复制原理中的瓶颈，我们可以采取以下策略：
MySQL 5.6+ 支持基于库（DATABASE）或基于逻辑时钟（LOGICAL_CLOCK）的并行复制。强烈建议开启基于逻辑时钟的并行复制，它能更好地识别无依赖的事务。
SET GLOBAL slave_parallel_type = 'LOGICAL_CLOCK'; SET GLOBAL slave_parallel_workers = 8;
将大事务拆分为多个小事务，减少单个事务在从库的执行时间，提高并行复制的效率。
调整从库的innodb_buffer_pool_size，确保热点数据在内存中；关闭从库的binlog（如果仅用于读）以减轻IO压力。
当发现主从数据不一致时，切勿直接重启从库。推荐使用pt-table-checksum和pt-table-sync工具进行检查和修复。或者使用MySQL 8.0引入的在线DDL和GTID特性，通过重放特定GTID区间的数据来修复差异。
登录从库执行 SHOW SLAVE STATUSG。关键关注两个字段：Slave_IO_Running 和 Slave_SQL_Running，两者必须均为 Yes。同时关注 Seconds_Behind_Master，该值越小越好，0表示无延迟，NULL表示连接异常。
GTID_PURGED 记录了当前服务器已经执行过或已经丢弃的事务集合。当你在从库恢复全量备份数据时，需要先将备份中包含的GTID集合设置到 gtid_purged 变量中，否则从库可能会拒绝应用后续的Binlog，因为认为这些事务已经执行过了。
在标准的主从架构中，从库默认是只读的（read_only=ON）。如果从库写入数据，会导致主从数据不一致。但在某些特殊场景（如读写分离中间件配置错误，或临时维护）下，可能会在从库写入。此时需注意，这些写入操作不会同步回主库，且可能干扰复制线程。
可以通过动态加载插件来实现。在主库执行 INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';，并设置 SET GLOBAL rpl_semi_sync_master_enabled = 1;。从库同理安装 rpl_semi_sync_slave 插件。