MySql复制总结

引言

​ 说MySql复制技术为其高可用性奠基一点不为过，当然实现MySql高可用性有很多种实现方式，比如共享存储、使用分布式协议在引擎级实现的高可用性等等。但是原生MySql复制技术是实现MySql高可用性，保证数据库安全稳定运行的最基础也是最重要的技术，它简单、原生，与MySql无限兼容，随着最新版本的发布，其已经能全方位满足大多数业务场景下的使用。因此有必要总结，总结，在总结！！！

常见概念

异步复制（Asynchronous replication）

async-replication-diagram.png

  • 逻辑上

    ​ MySql默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

  • 技术上

    ​ 主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。

全同步复制（Fully synchronous replication）

  • 逻辑上

    ​ 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

  • 技术上

    ​ 当主库提交事务之后，所有的从库节点必须收到、APPLY并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。

半同步复制（Semisynchronous replication，5.5）

semisync-replication-diagram.png

  • 逻辑上

    ​ 是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。

  • 技术上

    ​ 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

问题

很显然，从上面的概念来看，早期的MySql版本或者说早期MySql复制技术存在两个很显眼的问题：

  • 主从数据一致性
    • 异步复制：显然异步复制不能保证在master发生宕机或者网路异常不能把binglog同步到slave时，切换主备会造成数据丢失。
    • 全同步复制：如果我们在有多个slave的情况下，会严重影响master对客户端的响应速度，因此生产上基本很少用。
    • 半同步复制：从5.5版本开始，可以使用半同步插件，能解决部分全同步复制影响客户端响应及数据一致性问题，至于为什么只能解决部分，会在增强半同步段落说明。
  • 数据同步延迟
    • 复制的另外一个影响使用的地方在于数据延迟，特别在网络不稳定、master处理大事务的时候表现特别突出。这是因为MySql最早的主备复制只有两个线程，IO 线程负责从主库接收 Binlog 日志，并保存在本地的 relay log 中，SQL线程负责解析和重放 relay log 中的 event。当主库并行写入压力较大时，备库 IO 线程一般不会产生延迟，因为写 relay log 是顺序写，但是 SQL 线程重放的速度经常跟不上主库写入的速度，会造成主备延迟。如果延迟过大，relay log 一直在备库堆积，还可能把磁盘占满。

MySql的解决之道

增强半同步复制

为了解决数据一致性问题，5.7 的半同步最关键的一个新增参数是 rpl_semi_sync_master_wait_point ，主从一致性加强，支持在事务commit前等待ACK。

  • AFTER_COMMIT

    after_commit..png

    after commit是MySQL5.6半同步参数，区别于after sync，after sync是在接收ack确认以后主库在引擎层做提交，而after commit是先在引擎层做提交后等待ACK确认。因此，在写入数据后并且在从库确认之前，其他的客户端可以看到在这一事务。
    故障分析：
    1.binlog 未发送到从库:
    事务B获取到事务A提交的内容， 此时宕机故障切换到slave，事务B获取到的内容却丢失了。事务A commit没有收到反馈信息(则需要业务判断了)。
    2.binlog 已经发送给从库 :
    事务B获取到事务A提交的内容，故障切换到salve ，B仍然获取到A提交的内容，没毛病。事务A commit没有收到反馈信息，若重新执行该事务，则相当于执行两次A事务(则需要业务判断了)。

  • AFTER_SYNC （5.7的默认值）

    after_sync..png

    master 将每个事务写入Binlog , 传递到slave 刷新到磁盘(relay log)。master等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。

    实际上，客户端发出commit请求后，在主库上写入binlog并推送给slave，slave接收到binlog并写入relaylog，发送ACK确认已经接收binlog后，master在引擎层commit，客户端接收commit完成，此时其他会话才可以看见已提交的数据。
    故障分析：假设master在接收ACK确认时宕机，因为在引擎层并没有提交，HA切换到从库，因为binlog已经写入从库的relaylog，因此不会造成数据丢失，个人认为是目前比较完美的解决方式。

并行复制的演进

为了缓解数据延迟问题，很自然的想法是提高 SQL 线程重放的并行度，引入并行复制。

5.6 Schema 级别的并行复制

开启并行复制后，会启动多个 Worker 线程，原有的 SQL 线程变为 Coordinator 线程。
可以并行的事务分发给 Worker 线程执行；
不能并行的事务等待 Worker 线程全部结束后，再由 Coordinator 线程自己执行。
DDL 语句或者是跨 Schema 的语句不能并行执行。
这种并行复制的模式，对于多个 DB 同时更新才能有较高的并行度，但是更常见的情况是更新集中在同个一个 DB。
一个简单的改进，把 Schema 级别的并行复制改成 Table 级别，可以大幅度提高单库多表环境下的并行度。但是对于只有一个热点表的情况依然处理不了。

5.7 基于 Group Commit 的并行复制
Group Commit

引入 Group Commit之前，Binlog 和 InnoDB 日志是内部XA，为了保证 InnoDB 和 Binlog 提交顺序一致，实际是串行提交，执行序列如下：

  • InnoDB prepare
  • write/sync Binlog
  • InnoDB commit
    官方的 Group Commit 分为三个阶段，每个阶段有一个线程操作，三个阶段可以并发执行。
  • flush stage：Binlog 从 cache 写入文件
  • sync stage： 对 Binlog 做 fsync
  • commit stage：引擎层 commit
    这样 InnoDB prepare 成功的事务可以进入队列，每个阶段可以对队列事务统一做操作，提高了并行度。
    写Binlog 和 InnoDB commit 都是按照队列中的顺序，可以保证 Binlog 和事务提交顺序一致。
    image.png
    Binlog 中记录了 sequence_number 和 last_commited，如上图，MySqlBinlog 解析日志可以看到这两个值。
    sequence_number 是自增事务 ID，last_commited 代表上一个提交的事务 ID。
    如果两个事务的 last_commited 相同，说明这两个事务是在同一个 Group 内提交的。
LOGICAL_CLOCK 并行复制

slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一组的事务[last-commit相同]，没有锁冲突. 同一组，肯定没有冲突，否则没办法成为同一组)
slave-parallel-type=LOGICAL_CLOCK : Lock-Based模式(即便不是同一组的事务，只要事务之间没有锁冲突[prepare阶段]，就可以并发。 不在同一组，只要N个事务prepare阶段可以重叠，说明没有锁冲突)

5.7 引入了变量 slave_parallel_type，可选值 DATABASE、LOGICAL_CLOCK，DATABASE 就是和 5.6 中相同，Schema 级别的并行复制，而 LOGICAL_CLOCK 是基于 Group Commit 的并行复制，相比 5.6 极大提高了并行度。
Group Commit 实现了主库事务的并行提交。很显然的，主库能同时进入prepare阶段的事务之间不会冲突，那么这些事务在备库回放时也不会冲突。
Group Commit 中，last_commited 相同的事务，可以在备库并行回放。
MySql bin log 里面维护了两个变量
Logical_clock max_committed_transaction：记录上次 Group commit 时最大的 sequence_number，即上述 MySqlBinlog 中的 last_committed
Logical_clock transaction_counter：sequence_number 来源，每次分配 sequence_number 时 transaction_counter 进行递增，即当前最大的 sequence_number
5.7 的并行复制还有一点点弊端，如果如果主库并行度低，那么备库回放时也很难并行。

为此，5.7 引入了两个参数：

  • binlog_group_commit_sync_delay：等待延迟提交的时间，binlog提交后等待一段时间再 fsync。让每个 group 的事务更多，人为提高并行度。
  • binlog_group_commit_sync_no_delay_count：等待提交的最大事务数，如果等待时间没到，而事务数达到了，就立即 fsync。达到期望的并行度后立即提交，尽量缩小等待延迟。
8.0 基于 WriteSet 的并行复制

5.7 为了提高备库回放的速度，需要在主库尽量提高并行度。
8.0解决了这个问题，即使主库在串行提交的事务，只有互相不冲突，在备库就可以并行回放。
8.0 引入了参数 binlog_transaction_dependency_tracking 来控制事务依赖模式，让备库根据 commit timestamps 或者 write sets 并行回放事务，有三个取值：

  • COMMIT_ORDERE：使用 5.7 Group commit 的方式决定事务依赖
  • WRITESET：使用 WriteSet 的方式决定判定事务直接的冲突，发现冲突则依赖冲突事务，否则按照 COMMIT_ORDERE 方式决定依赖
  • WRITESET_SESSION：在 WRITESET 方式的基础上，保证同一个 session 内的事务不可并行
    WRITESET 是一个 hash 数组，大小由参数 binlog_transaction_dependency_history_size 决定。
    参数 transaction_write_set_extraction 决定 hash 算法，可选值：OFF、MURMUR32、XXHASH64，默认值 XXHASH64，如果
    WriteSet 记录了事务的更新行信息，决定 commit_parent时，使用事务自己的 session WriteSet 和 history WriteSet 进行比对，找到最近的冲突行，设为 commit_parent。如果 WriteSet 找不到 commit_parent，则还是使用 COMMIT_ORDERE 决定 commit_parent
  • 如何启用write-set并行复制
1
2
3
4
5
6
7
8
MySQL 5.7.22+ 支持基于write-set的并行复制  
# master  
loose-binlog_transaction_dependency_tracking = WRITESET  
loose-transaction_write_set_extraction = XXHASH64  
binlog_transaction_dependency_history_size = 25000 #默认  
#slave  
slave-parallel-type = LOGICAL_CLOCK  
slave-parallel-workers = 32
  • 核心原理
1
2
3
4
5
6
7
8
9
10
# master  
master端在记录binlog的last_committed方式变了  
基于commit-order的方式中，last_committed表示同一组的事务拥有同一个parent_commit           
基于write-set的方式中，last_committed的含义是保证冲突事务（相同记录）不能拥有同样的last_committed值   
当事务每次提交时，会计算修改的每个行记录的WriteSet值，然后查找哈希表中是否已经存在有同样的WriteSet       

1. 若无，WriteSet插入到哈希表，写入二进制日志的last_committed值保持不变，意味着上一个事务跟当前事务的last_committed相等，那么在slave就可以并行执行         
2. 若有，更新哈希表对应的writeset的value为sequence number，并且写入到二进制日志的last_committed值也要更新为sequnce_number。意味着，相同记录（冲突事务）回放，last_committed值必然不同，必须等待之前的一条记录回放完成后才能执行         
# slave       
slave的逻辑跟以前一样没有变化，last_committed相同的事务可以并行执行
  • 要不要开启并行复制
1
2
3
4
5
1. 基于order-commit的模式，本身并行复制已经很好了，如果并发量非常高，那么order-commit可以有很好的表现，如果并发量低，order-commit体现不了并行的优势。       
但是大家想想，并发量低的MySQL，根本也不需要并行复制吧       
2. 基于write-set的模式，这是目前并发度最高的并行复制了，基本可以解决大部分场景，如果并发量高，或者新搭建的slave需要快速追主库，这是最好的办法。         
3. 单线程复制 + 安全参数双0，这种模式同样拥有不随的表现，一般压力均可应付。       
以上三种情况，是目前解决延迟的最普遍的方法，目前我用的最多的是最后一种

  • 如何让slave的并行复制和master的事务执行的顺序一致

    5.7.19 之后，可以通过设置 slave_preserve_commit_order = 1

总结

随着 MySql 版本迭代，备库回放效率越来越高，为了保证主备同步时效性，可以尽量更新版本 MySql
同时，为了保证备库回放效率，应该根据业务模型适当设置复制相关参数。
比如 5.7 可以适当调大 binlog_group_commit_sync_delay 以提高主库并行度，同时设置 binlog_group_commit_sync_no_delay_count 在已满足并行度要求时主动提交，尽量减小延迟
在 8.0 中根据数据库配置高低设置 binlog_transaction_dependency_history_size，性能有富余的实例可以适当调大该参数，找到更小的 commit parent，提高备库回放并行度。内存和CPU紧张的实例最好避免在 WriteSet上消耗太多资源。binlog_transaction_dependency_history_size 过大，不光消耗内存，还会降低冲突查询的效率。

参考

MySql · 特性分析 · 8.0 WriteSet 并行复制
MySQL并行复制的深入浅出 | Focus on MySQL,Focus on Life
【MySql】5.7增强半同步AFTER SYNC&AFTER COMMIT - 简书
MySql并行复制的深入浅出 | Focus on MySql,Focus on Life
MySql系列（四）异步复制、全同步复制与半同步复制_数据库_xihuanyuye的博客-CSDN博客
【MySQL】5.7增强半同步AFTER SYNC&AFTER COMMIT - 简书