mysql主从复制原理_mysql高可用基础

MySQL主从复制基于binlog+relay log异步重放，需ROW格式、开启log-bin、唯一server-id；GTID提升切换可靠性但须全集群统一启用；延迟监控须结合Seconds_Behind_Master与File/Position比对。

主从复制靠的是 binlog + relay log 两级日志流转

MySQL 主从复制不是实时内存同步，而是基于日志的异步（或半同步）重放。主库把所有写操作记录到 binlog，从库通过 I/O 线程拉取并存为 relay log，再由 SQL 线程顺序执行其中的事件。

关键点在于：binlog 格式必须为 ROW 或 MIXED（不推荐 STATEMENT，因函数、临时表、非确定性语句易导致主从不一致）；主库需开启 log-bin，从库需设置 server-id 且唯一。

• binlog_format = ROW 是生产环境事实标准，能精确捕获行级变更
• 从库的 relay_log 文件默认命名规则是 hostname-relay-bin.xxxxxx，不建议手动修改其路径，否则 CHANGE MASTER TO 可能失效
• SQL 线程单线程回放 relay log，这是传统主从的性能瓶颈，MySQL 5.7+ 的 slave_parallel_workers > 0 可按库/事务分发，但需配合 slave_parallel_type = LOGICAL_CLOCK

START SLAVE 启动失败常见原因和检查项

执行 START SLAVE 后，SHOW SLAVE STATUS\G 中 Slave_IO_Running 或 Slave_SQL_Running 为 No，说明链路中断。不能只看 Seconds_Behind_Master 是否为 NULL。

破浪分红权返利系统基础版

破浪分红权返利系统是在破浪直销系统的基础上独立自主开发的一套稳定完善的购物商场网站管理系统，系统基于PHP+MYSQL开发，集购物商城、积分商城、商家联盟、会员营销机制等一体，模板与程序分离，集成网上支付，嵌入型短信应用API集成，使用简单、功能强大，多种返现模式可自由选择，为广大创业者者提供一个快速、高效、稳定、安全的电子商务系统。系统集O2O\C2C\B2C\B2B2C以及直销、分红、代理、分

下载

• IO 线程失败：检查主库网络可达性、复制用户权限（REPLICATION SLAVE）、主库 binlog 文件是否被清理（show master logs 对比 Master_Log_File）、主库磁盘满导致 binlog 写入失败
• SQL 线程失败：最常见于主从数据不一致引发的唯一键冲突、表结构不一致（如从库少字段）、DDL 执行失败（如 DROP TABLE 在从库不存在）、或 binlog_format = STATEMENT 下调用 NOW() / UUID() 导致时间/值不一致
• 跳过错误需谨慎：SET GLOBAL sql_slave_skip_counter = 1 仅对 STATEMENT 格式有效；mysqlbinlog --stop-never 解析 relay log 定位具体出错 SQL 更可靠

GTID 模式让主从切换更可控，但要求全集群统一开启

启用 GTID（gtid_mode = ON + enforce_gtid_consistency = ON）后，每个事务有全局唯一标识，不再依赖 File/Position。故障切换时，新主库可直接告诉从库“从这个 GTID 集合之后开始同步”，避免找错 binlog 偏移量。

• GTID 开启必须重启 MySQL 实例，且主从必须同时开启，混合模式不可行
• 使用 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 替代手工指定 MASTER_LOG_FILE 和 MASTER_LOG_POS
• GTID 不保证事务执行顺序完全一致（例如跨库并发事务在主库提交顺序与从库回放顺序可能不同），但能确保最终一致性
• 慎用 RESET MASTER：它会清空所有 binlog 并重置 GTID_EXECUTED，若从库尚未消费完，会导致无法继续同步

主从延迟大不只是网络问题，要盯住 Seconds_Behind_Master 的真实含义

Seconds_Behind_Master 显示的是 SQL 线程执行位置距离当前时间的秒数，不是 IO 线程拉取延迟。它为 0 仅表示“已执行完当前 relay log 中所有事件”，不代表没有积压——如果 IO 线程卡住，这个值可能长时间为 0，但实际已落后。

• 真正判断延迟要看：Relay_Master_Log_File 和 Exec_Master_Log_Pos 是否追上主库的 File/Position（用 SHOW MASTER STATUS 对比）
• 大事务是最大延迟源：一个耗时 30 分钟的 UPDATE 在从库单线程回放，就会卡住后续所有事务
• 从库负载过高（如慢查询、备份、统计分析）也会拖慢 SQL 线程，建议从库关闭 query_cache_type，避免缓存锁竞争
• 监控不能只看 Seconds_Behind_Master，应结合 Seconds_Behind_Master IS NULL（线程异常）、Retrieved_Gtid_Set 与 Executed_Gtid_Set 差集大小（GTID 模式下更准）

SELECT 
  @@global.gtid_mode AS gtid_mode,
  @@global.enforce_gtid_consistency AS enforce_gtid_consistency,
  @@global.binlog_format AS binlog_format,
  @@global.log_bin AS log_bin;