MySQL从5.6到8.0的复制演进

MySQL的主从复制

主从复制的基本原理

MySQL的主从架构依赖于Binlog功能。Master节点上产生Binlog并写入文件，主节点启动DUMP线程将Binlog发送给Slave。Slave节点启动IO线程和SQL线程，IO线程将Binlog读取到RelayLog，SQL线程从RelayLog中读取并执行，确保Slave上的SQL与Master一致。

复制延迟

复制延迟指的是Master执行事务后，Slave执行的事务时间差。由于Slave的IO线程和SQL线程是顺序读写，延迟主要来自于SQL线程的串行回放。MySQL5.5开始提供半同步复制，确保Binlog传输和Slave写入RelayLog后才提交事务，提高数据完整性。

MySQL5.6的并行复制

并行复制简介

MySQL5.6引入并行复制，但基于schema的并行效果有限。如果数据库实例包含多个schema且表数量较少，复制速度会有所提升。SQL线程变为coordinator线程，负责将可以并行的事务交付给worker线程执行。

并行复制的存在问题

基于schema的并行复制在多表或单库多表场景下效果较差，可能导致性能下降。

MySQL5.7的并行复制

并行复制简介

MySQL5.7的并行复制基于事务的组提交。Group Commit技术将事务分组，减少Binlog写入操作，提高并发提交效率。Slave上并行回放不再受限于主节点提交时的并发程度。

并行复制的存在问题

基于组提交的并行复制依赖于主节点的并发提交，主节点压力大时从节点回放速度受限。5.7引入参数binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count，优化主节点组提交，但从节点回放速度仍受限于主节点。

MySQL8.0的并行复制

基于WriteSet的并行复制

MySQL8.0引入基于WriteSet的事务依赖检测，Slave上的RelayLog回放速度不再受限于主节点提交时的并发度。Group Replication通过Paxso协议分发Binlog，Certify阶段使用WriteSet检测冲突。

WriteSet依赖检测条件

WriteSet基于主键和唯一键检测事务冲突。事务更新行的主键或非空唯一键的HASH值加入write_set，检测冲突时与已提交的事务write_set进行比对，确保依赖关系。write_set大小由binlog_transaction_dependency_history_size控制。

WriteSet参数

binlog_transaction_dependency_tracking参数可选值为COMMIT_ORDERED、WRITESET、WRITESET_SESSION。默认值为COMMIT_ORDERED， WRITESET和WRITESET_SESSION需要特定条件下使用。

总结

MySQL8.0的基于WriteSet的事务依赖检测，提升了从节点的并行回放能力，减少对主节点并发提交的依赖。Slave上可能比Master拥有更高吞吐量，提升复制性能。