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

MySQL主从复制基于binlog+relay log异步重放，需ROW格式、开启log-bin、唯一server-id；GTID提升切换可靠性但须全集群统一启用；延迟监控须结合Seconds_Behind_Master与File/Position比对。 主从复制靠的是 binlog + relay log 两级日志流转 MySQL 主从复制不是实时内存同步，而是基于日志的异步（或半同步）重放。主库把所有写操作记录到 ，从库通过 I/O 线程拉取并存为 ，再由 SQL 线程顺序执行其中的事件。 关键点在于：binlog 格式必须为 或 （不推荐 ，因函数、临时表、非确定性语句易导致主从不一致）；主库需开启 ，从库需设置 且唯一。 是生产环境事实标准，能精确捕获行级变更 从库的 文件默认命名规则是 ，不建议手动修改其路径，否则 可能失效 SQL 线程单线程回放 relay log，这是传统主从的 性能瓶颈 ，MySQL 5.7+ 的 可按库/事务分发，但需配合 START SLAVE 启动失败常见原因和检查项 执行 后， 中 或 为 ，说明链路中断。不能只看 是否为 。 MySQL（Linux） MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。 下载 IO 线程失败：检查主库网络可达性、复制用户权限（ ）、主库 文件是否被清理（ 对比 ）、主库磁盘满导致 写入失败 SQL 线程失败：最常见于主从数据不一致引发的唯一键冲突、表结构不一致（如从库少字段）、DDL 执行失败（如 在从库不存在）、或 下调用 / 导致时间/值不一致 跳过错误需谨慎： 仅对 格式有效； 解析 relay log 定位具体出错 SQL 更可靠 GTID 模式让主从切换更可控，但要求全集群统一开启 启用 GTID（ + ）后，每个事务有全局唯一标识，不再依赖 。故障切换时，新主库可直接告诉从库“从这个 GTID 集合之后开始同步”，避免找错 binlog 偏移量。 GTID 开启必须重启 MySQL 实例，且主从必须同时开启，混合模式不可行 使用 替代手工指定 和 GTID 不保证事务执行顺序完全一致（例如跨库并发事务在主库提交顺序与从库回放顺序可能不同），但能确保最终一致性 慎用 ：它会清空所有 binlog 并重置 GTID_EXECUTED，若从库尚未消费完，会导致无法继续同步 主从延迟大不只是 网络问题 ，要盯住 Seconds_Behind_Master 的真实含义 显示的是 SQL 线程执行位置距离当前时间的秒数，不是 IO 线程拉取延迟。它为 仅表示“已执行完当前 relay log 中所有事件”，不代表没有积压——如果 IO 线程卡住，这个值可能长时间为 ，但实际已落后。 真正判断延迟要看： 和 是否追上主库的 / （用 对比） 大事务是最大延迟源：一个耗时 30 分钟的 在从库单线程回放，就会卡住后续所有事务 从库负载过高（如慢查询、备份、统计分析）也会拖慢 SQL 线程，建议从库关闭 ，避免缓存锁竞争 监控不能只看 ，应结合 （线程异常）、 与 差集大小（GTID 模式下更准） 主从复制看似配置简单，但 binlog 格式、GTID 开关时机、SQL 线程卡点、以及监控指标的真实含义，这几处一旦设错或忽略，高可用就变成高不可靠。