理解主从复制、半同步与GTID的核心机制
MySQL主从复制的数据流转始于主库将数据变更写入Binary Log（Binlog），随后通过网络传输至从库。从库的I/O线程将接收到的Binlog事件写入本地的Relay Log，最后由SQL线程读取Relay Log并重放事务。传统异步复制中，主库提交事务后无需等待从库确认，存在主库宕机导致数据丢失的风险。半同步复制在此基础上引入ACK确认机制：主库在事务提交前，会等待至少一个从库将Binlog写入磁盘并返回确认信号，若等待超时则自动降级为异步模式以保障可用性。GTID（全局事务标识符）由server_uuid与transaction_id组成，确保每个事务在整个复制拓扑中全局唯一。半同步解决的是“数据安全性与提交确认”问题，而GTID解决的是“复制位置管理与故障恢复”问题，两者互补而非替代。通过GTID，从库可自动识别已执行事务，避免重复执行或遗漏。
配置半同步复制并验证事务确认机制
启用半同步复制需先安装对应插件。在主库执行INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';，从库执行INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';。随后在配置文件或动态设置中开启：主库设置rpl_semi_sync_master_enabled=1，从库设置rpl_semi_sync_slave_enabled=1。核心参数rpl_semi_sync_master_timeout（默认10000毫秒）控制主库等待ACK的超时时间，超时后主库将自动切换为异步复制以保障业务连续性。建立基础复制需创建专用复制用户并授权REPLICATION SLAVE，从库通过CHANGE REPLICATION SOURCE TO指定主库信息并启动。验证半同步是否生效，可查询状态变量：主库执行SHOW STATUS LIKE 'Rpl_semi_sync_master_status';，返回ON表示已激活；SHOW STATUS LIKE 'Rpl_semi_sync_master_yes_tx';记录成功半同步提交的事务数。若该值持续增长，说明半同步机制正在正常工作。
启用GTID复制与自动故障定位
启用GTID模式需在主从节点均配置gtid_mode=ON与enforce_gtid_consistency=ON，并重启MySQL服务使参数生效。配置完成后，从库建立复制关系时无需再手动指定MASTER_LOG_FILE和MASTER_LOG_POS，只需执行CHANGE REPLICATION SOURCE TO SOURCE_HOST='主库IP', SOURCE_USER='repl_user', SOURCE_PASSWORD='password', SOURCE_AUTO_POSITION=1;即可。SOURCE_AUTO_POSITION=1是GTID自动定位的核心开关，从库启动后会向主库发送自身已执行的GTID集合，主库自动比对并发送缺失的事务流。这一机制彻底消除了传统基于Binlog文件名和Position号切换时容易出现的偏移量计算错误。在故障切换或主从重构场景中，运维人员只需确保新从库的gtid_purged或gtid_executed集合正确，即可无缝接管复制流，大幅降低人工干预成本与误操作风险。
检查复制状态、故障切换与常见避坑
日常巡检需依赖SHOW REPLICA STATUS\G命令。重点关注Replica_IO_Running与Replica_SQL_Running是否均为Yes，Seconds_Behind_Source反映复制延迟，Last_Error记录中断原因。GTID模式下，Retrieved_Gtid_Set与Executed_Gtid_Set可直观对比事务同步进度。当网络中断时，IO线程状态变为Connecting，恢复后自动重连；若半同步超时触发降级，主库状态变量Rpl_semi_sync_master_status会跳转为OFF，网络恢复后需手动或依赖插件自动重新协商。常见避坑要点包括：严禁在复制拓扑中重复使用server_uuid，否则GTID集合将发生冲突导致复制中断；半同步插件安装后若未正确授权或未在从库开启对应插件，主库状态将始终为OFF；GTID模式下禁止使用SET SQL_LOG_BIN=0跳过日志记录，否则会破坏GTID连续性。规范配置与定期监控是保障高可用架构稳定运行的基石。
