主从复制是MySQL生产环境中最常用的高可用与扩展方案，读写分离、故障切换、数据备份几乎都建立在这项技术之上。MySQL 5.6作为复制功能演进的一个重要版本，引入了GTID全局事务标识、多线程复制、崩溃安全的中继日志等特性，让复制体系相比早期版本发生了质的变化。本文将从复制的基本原理讲起，逐步展开MySQL 5.6中GTID复制的配置方法、多线程复制的使用技巧，以及延迟问题的排查与优化思路。
一、MySQL 5.6复制的核心原理
MySQL的主从复制本质上是一个基于日志的事件回放过程。主库把所有修改数据的操作记录到二进制日志binlog中，从库通过IO线程拉取这些日志事件，保存到本地的中继日志relay log里，再由SQL线程读取relay log并重放其中的事件，从而使从库数据与主库保持一致。整个复制链条涉及三个关键文件和两个线程：主库上的binlog、从库上的relay log和master.info，以及从库的IO线程与SQL线程。
具体流程可以拆解为四步。第一步，从库执行CHANGE MASTER TO后，IO线程会连接主库并请求指定日志文件名和位置之后的内容。第二步，主库收到请求后启动一个Binlog Dump线程，持续读取binlog并将新事件发送给从库。第三步，从库IO线程接收事件后写入relay log，同时更新master.info文件记录已读取到的位点。第四步，SQL线程读取relay log中的事件并执行，执行进度记录在relay-log.info中。在MySQL 5.6之前，这两个info文件默认是普通文件，异常断电容易导致复制中断，5.6开始支持将它们迁移到系统表中，显著提升了崩溃安全性。
需要特别注意的是，复制是异步的。主库提交事务后并不等待从库确认，网络抖动或从库压力大都可能造成数据延迟，这是后续讨论复制延迟优化的根源。另外，binlog有三种格式：STATEMENT记录原始SQL语句，ROW记录每行数据的变更，MIXED是两者的混合。ROW格式在MySQL 5.6中已是推荐配置，虽然日志量更大，但主从一致性最有保障，尤其适合使用UUID、NOW等不确定函数的场景。
二、GTID复制：MySQL 5.6最重要的新特性
GTID的全称是Global Transaction Identifier，即全局事务标识符。在传统复制中，切换主库或重建从库时，运维人员必须手动找出新的binlog文件名和位置，一旦算错就会导致数据丢失或重复。GTID为每个事务分配一个全局唯一的编号，格式为server_uuid:transaction_id，例如3E11FA47-71CA-11E1-9E33-C80AA9429562:23。从库可以自动判断哪些事务已经执行过，搭建复制时只需一条语句指定主库位置即可，无需再关心文件名和位点。
开启GTID需要在主库和从库的my.cnf中同时配置以下参数，注意这些参数修改后需要重启MySQL才能生效：
[mysqld] gtid_mode=ON enforce_gtid_consistency=ON log_bin=mysql-bin log_slave_updates=ON binlog_format=ROW server_id=1
其中log_slave_updates的含义是让从库把SQL线程执行的事务也写入自己的binlog。在GTID体系中这是必须开启的，因为故障切换时新的从库需要从这台机器上补齐事务。enforce_gtid_consistency则禁止那些无法保证事务安全性的操作，例如在事务内使用CREATE TABLE ... SELECT，开启后遇到这类语句会直接报错，这是为了确保GTID位图始终能准确描述事务的执行状态。
配置完成后，在主库创建复制账号并授权：
-- 创建专用复制账号，限制来源IP提升安全性 CREATE USER 'repl'@'192.168.1.%' IDENTIFIED BY 'Repl@123456'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'192.168.1.%'; FLUSH PRIVILEGES;
在从库上执行复制配置，可以看到GTID方式下无需指定MASTER_LOG_FILE和MASTER_LOG_POS：
CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_PORT=3306, MASTER_USER='repl', MASTER_PASSWORD='Repl@123456', MASTER_AUTO_POSITION=1; START SLAVE; SHOW SLAVE STATUS\G
MASTER_AUTO_POSITION=1表示启用自动位置协商，从库会把自己的GTID执行集合发给主库，主库据此计算出缺失的事务并补发。检查SHOW SLAVE STATUS的输出时，重点确认Slave_IO_Running和Slave_SQL_Running两个状态都为Yes，Retrieved_Gtid_Set和Executed_Gtid_Set则分别显示已接收和已执行的GTID范围，是排障的重要依据。
三、多线程复制与延迟优化
单线程回放是传统复制最大的性能瓶颈。主库上多个并发会话写入的事务，到了从库只能由一个SQL线程串行执行，写入压力一大，从库的延迟就会不断累积。MySQL 5.6引入了并行回放机制，通过参数slave_parallel_workers开启多线程复制。它的并行粒度是库级别，即不同数据库schema下的事务可以由不同的worker线程同时回放，但同一个库内的事务仍然串行。
配置方法很简单，在从库上执行：
STOP SLAVE SQL_THREAD; SET GLOBAL slave_parallel_workers=4; START SLAVE SQL_THREAD; -- 查看worker线程状态 SHOW PROCESSLIST; SHOW STATUS LIKE 'Slave_parallel_workers';
从库重启SQL线程后，SHOW PROCESSLIST中会多出若干个Slave_worker线程。需要注意的是，如果你的业务集中在单个数据库中，库级并行带来的收益会非常有限，这种场景要等到5.7的基于组提交的并行复制才能根本解决。此外，开启多线程前应确认binlog_format为ROW且gtid_mode为ON，这是5.6并行复制的官方推荐组合。
除了开启并行复制，缓解延迟还可以从多个角度入手。在硬件层面，从库使用SSD并适当加大innodb_flush_log_at_trx_commit的刷盘间隔，例如改为2，可以减少回放时的IO等待。在参数层面，sync_binlog在从库上可以放宽，因为从库数据本就来自主库，无需同等强度的持久化保证。在架构层面，将大事务拆小效果最明显，一个执行十分钟的大事务在从库同样要串行回放十分钟，期间延迟会持续增长。还可以部署半同步复制，让主库至少等待一个从库收到binlog后才向客户端返回成功，虽然不能消除回放延迟，但能保证数据不丢失，为故障切换提供安全基础。
日常监控方面，Seconds_Behind_Master是最直观的延迟指标，但它基于事件时间戳计算，网络中断期间可能显示不准确，更可靠的做法是对比主从的GTID集合，或者在主库定期写入心跳表并检查从库的同步时间。一旦出现复制中断，应先看SHOW SLAVE STATUS中的Last_SQL_Error定位报错事务，再结合Errno决定是跳过该事务还是修复数据后重建复制，切不可盲目使用SQL_SLAVE_SKIP_COUNTER，否则容易造成主从数据永久性不一致。
四、常见问题与最佳实践
生产环境中MySQL 5.6复制有几个高频问题值得提前规避。第一是server_id必须全局唯一，主从配置相同的server_id会导致IO线程频繁断开重连。第二是复制过滤的坑，在从库上配置replicate_ignore_db后，跨库操作可能被意外过滤，官方更推荐使用replicate_wild_ignore_table按表过滤。第三是GTID环境下的经典错误，从库如果误写入数据后再连接新主库，会因为GTID冲突而中断，因此从库务必设置read_only=ON，并配合super_read_only思路限制有SUPER权限的账号写入。
在版本升级和数据修复场景中，经常需要重建从库。传统做法是mysqldump全量备份加binlog位点对接，GTID时代更简洁的方式是在dump时加上SET-GTID-PURGED选项，恢复后直接CHANGE MASTER TO即可自动补齐差量。定期演练主从切换也很重要，GTID让切换操作从繁琐的位点计算变成一行CHANGE MASTER语句，但切换脚本的正确性只有通过演练才能验证。掌握这些原理与实践，MySQL 5.6的复制体系就能真正为业务的高可用保驾护航。