【MySQL InnoDB 内核】主从复制：异步、半同步、GTID 与并行回放
内容提要
本文探讨了MySQL 8.0.36的主从复制机制，包括异步、半同步和GTID复制，分析了复制拓扑、线程模型、binlog格式、并行复制和延迟诊断等关键点。强调了Seconds_Behind_Master的计算陷阱及其不可靠性，建议使用性能模式和GTID集合进行对比。同时，指出了与PostgreSQL流复制的差异，特别是在日志类型、回放和并行处理方面。
关键要点
-
MySQL 8.0.36 的主从复制机制包括异步、半同步和 GTID 复制。
-
复制拓扑为经典的一主一从，涉及 binlog dump、IO 线程、relay log 和 SQL 线程。
-
binlog 格式有 STATEMENT、ROW 和 MIXED，推荐使用 ROW 格式以避免非确定性函数风险。
-
GTID（全局事务标识符）用于跟踪已应用事务，简化故障转移过程。
-
并行复制（MTS）依赖于写集合和 schema 约束，支持不同库的并行处理。
-
半同步复制确保主库 binlog 写入从库后才返回客户端 commit 成功，超时会降级为异步。
-
Seconds_Behind_Master 的计算可能失真，建议使用 performance_schema 进行更可靠的延迟诊断。
-
与 PostgreSQL 流复制相比，MySQL 的日志类型和回放机制存在显著差异，特别是在并行处理方面。
延伸解读
主从复制的延迟诊断
在MySQL主从复制中，Seconds_Behind_Master（SBM）并不总是可靠的延迟指标。它可能在主库没有新写入时显示为0，即使从库实际上存在延迟。因此，建议使用performance_schema中的相关表进行更准确的延迟诊断，以便更好地监控和优化复制性能。
GTID的优势与局限
GTID（全局事务标识符）在简化故障转移和事务跟踪方面具有显著优势，但在使用时需注意其局限性。特别是在执行RESET MASTER时，可能会影响GTID的完整性，因此在生产环境中应谨慎操作，确保数据一致性。
并行复制的应用场景
MySQL的并行复制（MTS）可以显著提高从库的处理能力，但其效果依赖于写集合和schema约束。对于高并发的应用场景，合理配置并行复制参数可以有效减少延迟，但需要注意避免过度并行导致的资源争用问题。
延伸问答
MySQL 8.0.36 的主从复制机制有哪些类型？
MySQL 8.0.36 的主从复制机制包括异步、半同步和 GTID 复制。
什么是 GTID，它在主从复制中有什么作用？
GTID（全局事务标识符）用于跟踪已应用事务，简化故障转移过程。
如何诊断 MySQL 主从复制的延迟？
可以使用 performance_schema 进行更可靠的延迟诊断，关注 Relay_Log_Space 和 Executed_Gtid_Set 等指标。
MySQL 的半同步复制是如何工作的？
半同步复制确保主库 binlog 写入从库后才返回客户端 commit 成功，超时会降级为异步。
MySQL 的 Seconds_Behind_Master 计算有什么陷阱？
Seconds_Behind_Master 的计算可能失真，特别是在主库无新写入或大事务的情况下。
MySQL 的并行复制是如何实现的？
并行复制依赖于写集合和 schema 约束，支持不同库的并行处理。
