MySQL replication概述

• 复制使来自一个MySQL数据库服务器（称为源/主库）的数据能够复制到一个或多个MySQL数据库服务器（称为副本/从/备/只读库）

• 默认情况下，复制是异步的

• 复制使得MySQL从单机走向集群
  

• 异步复制：

  • 源（A库）发送事务的更新到副本（B库），源（A库）上事务的提交不等待副本（B库）的任何反馈
  • 副本（B库）不需要永久连接源（A库）
  • 根据配置，副本（B库）可以复制源（A库）中的所有数据库、选定的数据库，甚至选定的表。
    

• 半同步复制：内置异步复制，源（A库）发送事务的更新到副本（B库），源（A库）上事务的提交需要等待副本（B库）接收到这个事务的反馈

• 半同步复制包括两种复制状态：同步复制状态和异步复制状态，绝大多数情况下处于同步复制状态，在网络闪断和大事务的情况下为了保护主库的高性能，自动转换为异步复制状态，副本库追赶上源库后，会自动转换为同步复制状态。

• 半同步复制实际上是弹性同步复制，自推出以来，被广泛使用。
  

• DML和DDL语句对源数据库产生的改变会被写入BINLOG，然后被复制到副本数据库

• SELECT语句不对数据库产生改变，所以不会被复制到副本数据库

• 副本数据库也可以把DML和DDL语句对数据库产生的改变写入BINLOG
  

MySQL replication拓扑

• 简单拓扑
  

• 链式拓扑
  

• 任意拓扑
  

The binary log

The binary log是什么？

• 是连续的逻辑流，记录主库正在发生的改变

• 这个逻辑流会被持久化到文件中

• 每个事务都包含一组LOG EVENTS，始于GTID LOG EVENT，终于COMMIT LOG EVENT。如下图所示：
  

• 注：The binary log简称binlog

The binary log有什么用途？

• 实现数据流式复制，是MySQL replication的根基
• 保存数据库的变化历史
• 使得MySQL从单机走向集群
• BINLOG的格式非常的规范和标准，因而社区有很多基于BINLOG的工具，进而产生了极强的MySQL生态粘性
• 是平滑迁移的基础
• 基于任意时间点的恢复
• …

The binary log持久化在哪里？

• 持久化在一组文件中
  • 主库正在发生的变化被持久化在一组文件中，这组文件的后缀是递增的
  • 这组文件的名字保存在一个索引文件中，比如：binlog.index
    

多线程只读库和备库

• 协调者从relay log（中继日志）中读取事务，并且安排这些事务给多个工作者
• 多个工作者可以并发执行在主库上并发执行的事务，能跟上主库吗？
  

自动连接

自动连接 - 有什么用途？

• 备库和只读库崩溃恢复后，能够自动连接到主库继续复制
• 主库和备库切换后，只读库能自动连接到新主库继续复制
• 减少了维护成本和中断时间
• 增加了集群的可用性
• 支持任意拓扑，如下图所示：
  

自动连接 - 基于什么做到的？

• 自动连接是基于GTID做到的

• 主库给每个事务分配一个全局事务标识符（GTID）

  • 全局事务标识符由server_uuid:number组成，例如：a61678ba-4889-4279-9e58:1
  • server_uuid标识一个数据库并且是全局唯一的
  • number是同一个数据库上的每个事务的编号，每个事务递增一

• 写全局事务标识符（GTID）到binlog中，每个事务一个GTID
  

自动连接 - 怎么做到的？

• 副本（B库）重新执行来自源（A库）的事务时会保存这个事务原有的GTID
• 副本通过GTID做到不会重新执行同一个事务两次
• 源与副本之间的协议：
  • 副本发送已经执行的事务的GTID集合到源
  • 源发送所有其他的事务到副本
    

高可靠怎么做到的？

高可靠怎么做到的 - 同步复制状态

• 主库与备库之间是半同步复制关系，绝大多数情况下处于半同步复制的同步复制状态
• 在同步复制状态下，主库崩溃，直接切换到备库，备库升级成新主库对外服务
  

高可靠怎么做到的 - 异步复制状态

• 网络闪断或主库执行大事务时，半同步复制处于异步复制状态下，此时主库崩溃，必须把主库拉起（为什么？），对外服务，中断时间稍长。
  

高可靠怎么做到的 - 手动切换原理

• 主库与备库支持手动切换，手动切换后，主库降级成新备库，备库升级成新主库
  

异地灾备怎么做到的？

• 主库通过DRS异步复制到异地灾难备库，为什么不是半同步复制？
• 主库和备库所在区域不可用时，异地灾难备库升级成主库对外服务。
  

异地灾备 - 双活

• 主库A通过DRS异步复制事务到主库B，同时主库B通过DRS异步复制事务到主库A
• 主库A与备库A之间是半同步复制关系
• 主库B与备库B之间是半同步复制关系
  

高性能的只读库和备库

• 只读库和备库的并发度低于主库的并发度

  • 导致只读库复制延迟比较大
  • 导致主备切换中断的时间长

• 通过非持久化的技术，事务在内存中执行和提交，很大地提高了只读库和备库的性能，缩短了复制延迟

• 事务提交不持久化，怎么保证只读库和备库崩溃后事务不丢失？

  • 没有被持久化事务在数据库崩溃重启后是丢失了的
  • 但是这些丢失了的事务可以通过基于GTID的自动连接从主库上重新拉取过来，重新执行。
  • 为什么主库不能使用非持久化的技术？

怎么恢复到任意指定的时刻？

• 数据库崩溃后，怎么恢复到任意指定的时刻？
  • binlog保存了数据库的变化历史，所以回放这些binlog到指定的时刻，就能把数据库恢复到指定的时刻
  • 华为云RDS for MySQL主库定期做全量备份，以这个全量备份为基础，回放增量的binlog到指定的时刻，就能把数据库恢复到指定的时刻