MySQL高级讲座篇之：探讨MySQL`5.7`和`8.0`主从复制的性能优化与架构演进。

嘿，大家好！我是老码农，今天咱们聊聊MySQL主从复制，尤其是5.7和8.0这两个版本，在性能优化和架构演进上的一些门道。保证让大家听得明白，用得上，还能时不时会心一笑。

开场白：复制，数据库的“影分身术”

话说，单机数据库再牛，也怕扛不住高并发，更怕万一宕机。怎么办？那就得靠复制，让数据有多份备份，就像鸣人的影分身术一样。MySQL的主从复制，就是干这个的。

第一回合：5.7时代的挣扎

MySQL 5.7的主从复制，虽然已经很成熟了，但还是有些“老年病”。咱们先来看看它的基本架构：

• Master (主库): 负责写入数据，并将变更记录到二进制日志 (Binary Log，简称Binlog)。
• Slave (从库): 从Master拉取Binlog，然后在本地重放这些变更，保持数据同步。
• Relay Log (中继日志): Slave从Master拉取的Binlog，先存放在Relay Log中，然后再执行。

5. 7的复制架构，简单来说就是：主库写，从库读，中间靠Binlog传递消息。

5.7的性能瓶颈与优化

5. 7的复制，经常会遇到以下问题：

   • 单线程复制： 默认情况下，Slave只有一个SQL线程来执行Relay Log中的事件。这意味着，即使Master有多核CPU，Slave也只能“一条道走到黑”，严重拖慢复制速度。
   • Binlog格式： 5.7支持STATEMENT、ROW和MIXED三种Binlog格式。STATEMENT格式记录的是SQL语句，简单省空间，但有些语句在主从环境下的执行结果可能不一致。ROW格式记录的是每一行数据的变更，最可靠，但Binlog体积会很大。MIXED格式则是根据SQL语句自动选择STATEMENT或ROW。
   • GTID的支持： GTID (Global Transaction ID) 是全局事务ID，可以简化Failover和复制拓扑管理。5.7开始支持GTID，但默认是关闭的。

5.7的优化策略

针对这些问题，我们可以采取以下优化措施：

• 多线程复制 (mts): MySQL 5.7引入了多线程复制，允许Slave使用多个SQL线程并行执行Relay Log中的事件。

  • 配置： 在Slave的my.cnf文件中，设置以下参数：

    slave_parallel_type=LOGICAL_CLOCK
    slave_parallel_workers=8  # 根据CPU核心数调整

    slave_parallel_type设置为LOGICAL_CLOCK，表示按照逻辑时钟进行并行复制。slave_parallel_workers设置SQL线程的数量。

  • 原理： 多线程复制并不是完全无限制的并行。它会根据事务的依赖关系，将事务分成不同的组，同一组内的事务必须串行执行，不同组的事务可以并行执行。

• Binlog格式的选择： 尽量选择ROW格式，虽然体积大一些，但保证数据一致性更重要。如果对一致性要求不高，或者数据库中的SQL语句都很简单，可以考虑MIXED格式。

  • 配置： 在Master的my.cnf文件中，设置以下参数：

    binlog_format=ROW

• 启用GTID： 启用GTID可以简化Failover和复制拓扑管理。

  • 配置： 在Master和Slave的my.cnf文件中，设置以下参数：

    gtid_mode=ON
    enforce_gtid_consistency=ON
    log_slave_updates=ON  # 在Slave上也要开启Binlog

    gtid_mode=ON启用GTID。enforce_gtid_consistency=ON强制GTID一致性，不允许执行不安全的SQL语句。log_slave_updates=ON表示Slave也要开启Binlog，方便构建级联复制。

• Binlog优化： 调整binlog_cache_size和max_binlog_size等参数，控制Binlog的缓存大小和最大体积，避免Binlog占用过多磁盘空间。

  • 配置： 在Master的my.cnf文件中，设置以下参数：

    binlog_cache_size=4M
    max_binlog_size=500M

第二回合：8.0时代的飞跃

MySQL 8.0带来了很多改进，主从复制也得到了很大的提升。

8.0的新特性

• 更快的复制速度： 8.0对多线程复制进行了优化，可以更好地利用多核CPU，提高复制速度。
• 原子事务： 8.0支持原子事务，保证事务的完整性，即使在复制过程中发生故障，也能保证数据一致性。
• Invisible Indexes： 8.0引入了Invisible Indexes，允许隐藏索引，方便进行性能测试和优化。
• 更好的JSON支持： 8.0对JSON的支持更加完善，可以更方便地存储和查询JSON数据。

8.0的优化策略

8. 0在5.7的基础上，又增加了一些新的优化手段：

   • 优化多线程复制： 8.0对多线程复制进行了改进，可以更好地利用多核CPU，提高复制速度。无需手动调整，默认配置即可获得较好的性能。

   • Binlog Group Commit (BGC): BGC是MySQL 5.6引入的，但在8.0中得到了进一步优化。BGC可以将多个事务的Binlog写入操作合并成一次，减少磁盘IO，提高性能。

     • 原理： BGC将多个事务的提交操作放入一个队列中，然后由一个线程负责将这些事务的Binlog写入磁盘。这样可以减少磁盘IO次数，提高性能。
     • 配置： BGC的参数主要有binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count。binlog_group_commit_sync_delay表示等待多长时间才将Binlog写入磁盘。binlog_group_commit_sync_no_delay_count表示有多少个事务可以不等待，直接写入磁盘。

   • 并行复制优化： 8.0对并行复制进行了优化，可以更好地处理大事务和复杂事务。

   • 监控： 8.0提供了更多的监控指标，可以更方便地监控复制状态和性能。

代码示例：8.0的GTID配置

8. 0的GTID配置和5.7类似，但更加简单：

gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON

第三回合：架构演进

主从复制不仅仅是简单的“一主一从”，还可以构建更复杂的架构，满足不同的需求。

常见的复制架构

• 一主多从： 一个Master，多个Slave。Slave可以分担读压力，提高系统整体性能。

  • 适用场景： 读多写少的应用。
  • 优点： 简单，易于维护。
  • 缺点： Master压力大，容易成为瓶颈。

• 级联复制： Master -> Slave1 -> Slave2 -> Slave3… Slave从另一个Slave拉取Binlog，可以减轻Master的压力。

  • 适用场景： 大型应用，需要分担Master压力。
  • 优点： 可以减轻Master压力。
  • 缺点： 复制延迟可能会比较大。

• 双主复制： 两个Master，互相复制数据。可以实现高可用。

  • 适用场景： 需要高可用的应用。
  • 优点： 高可用。
  • 缺点： 配置复杂，容易出现数据冲突。

• MGR (MySQL Group Replication): MGR是MySQL 5.7.17引入的，基于Paxos协议实现的多主复制方案。

  • 原理： MGR是一个分布式数据库集群，所有节点都可以写入数据。每个事务在提交之前，需要经过集群内多数节点的投票，只有获得多数节点的同意，才能提交。
  • 优点： 高可用，数据一致性强。
  • 缺点： 性能相对较低，配置复杂。

架构选择的原则

选择哪种复制架构，需要根据实际情况进行权衡。一般来说，需要考虑以下因素：

• 业务需求： 是读多写少，还是写多读少？是否需要高可用？
• 数据量： 数据量越大，复制延迟可能会越大。
• 硬件资源： 硬件资源越充足，可以采用更复杂的架构。
• 维护成本： 架构越复杂，维护成本越高。

表格总结

特性/架构	5.7	8.0	优点	缺点	适用场景
多线程复制	需要手动配置，性能提升有限	优化后默认开启，性能更好	提高复制速度	配置复杂 (5.7)	读多写少的应用，需要快速复制数据
Binlog格式	STATEMENT, ROW, MIXED	STATEMENT, ROW, MIXED	ROW格式保证数据一致性	ROW格式Binlog体积大	对数据一致性要求高的应用
GTID	支持，但需要手动开启	默认开启，更易于管理	简化Failover和复制拓扑管理		需要高可用的应用
MGR	不支持	支持	高可用，数据一致性强	性能相对较低，配置复杂	需要高可用和强一致性的应用
一主多从	简单，易于维护	简单，易于维护	简单，易于维护	Master压力大	读多写少的应用
级联复制	减轻Master压力	减轻Master压力	可以减轻Master压力	复制延迟可能会比较大	大型应用，需要分担Master压力
双主复制	高可用，配置复杂，容易数据冲突	高可用，配置复杂，容易数据冲突	高可用	配置复杂，容易数据冲突	需要高可用的应用

结束语：复制之路，永无止境

MySQL主从复制是一个不断演进的技术，从5.7到8.0，性能和功能都得到了很大的提升。但是，复制之路永无止境，我们需要不断学习新的技术，才能构建更高效、更可靠的数据库系统。

希望今天的讲座对大家有所帮助。记住，理论要结合实践，多动手，多思考，才能真正掌握这些技术。

下次再见！