MySQL主从复制 —— 作用、原理、数据一致性，异步复制、半同步复制、组复制

文章目录
一、作用
二、原理
三、同步数据一致性

• 3.1 主从同步要求
  
• 3.2 主从延迟原因、直接表现
  
• 3.3 减少主从延迟的方案
  
• 3.4 数据一致性问题的解决
  
  
  
  • 3.4.1 异步复制
    
  • 3.4.2 半同步复制
    
  • 3.4.3 组复制
    
  
  

MySQL主从复制的核心就是二进制日志binlog
二进制日志（BINLOG）记录了所有的 DDL（数据定义语言，创建库、表）语句和 DML（数据操纵语言，增删改）语句，但不包括数据查询（SELECT、SHOW）语句。
一、作用

• 读写分离
  
• 数据备份
  
• 高可用性
  

二、原理

实际上主从同步是基于binlog进行数据同步的。在主从复制过程中，会基于3个线程来操作，一个主库线程、两个从库线程

• 二进制日志转储线程（Binglog dump thread）是一个主库线程，当从库线程连接时，主库可以将二进制日志发送给从库，当主库读取事件时，会在Binlog上加锁，读取完成后释放锁
  
• 从库I/O线程连接主库，向主库发送请求更新Binlog。这时从库的I/O线程就可以读取主库的二进制日志转储线程的Binlog更新部分，并且拷贝到本地的中继日志relaylog
  
• 从库SQL线程会读取从库中的中继日志，并且执行日志中的事件，将从库中的数据与主库保持同步
  

复制过程就是将binlog中的数据从主库传输到从库上，这个过程一般是异步的，即主库上执行事务操作的线程不会等待复制binlog的线程同步完成。主从复制概括为 ：在Master端开启binlog ，从库将master的binlog拷贝到它的中继日志relay log，slave端重放binlog 从而达到主从数据一致
简单来说分成三步：

• 写入binlog：Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中
  
• 同步binlog：从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log（从库将master的binlog拷贝到它的中继日志）
  
• 回放binlog：slave重做中继日志中的事件，将改变应用到自己的数据库中
  

MySQL复制时异步且串行化的，重启后从接入点开始复制。

具体详细过程如下：

• MySQL主库在收到客户端提交事务的请求之后，会先写入binlog，再提交事务，更新存储引擎中的数据，事务提交完成后，返回给客户端"操作成功"的响应。
  
• 从库会创建一个专门的I/O线程，连接主库的log dump线程，来接收主库的binlog日志，再把binlog信息写入relay log的中继日志里，再返回给主库"复制成功"的响应
  
• 从库会创建一个用于回放binlog的线程，去读relay log中继日志，然后回放binlog 更新存储引擎中的数据，最终实现主从的数据一致性。
  

在完成主从复制之后，你就可以在写数据时只写主库、读数据时只读从库，这样即使写请求会锁表或者锁记录，也不会影响读请求的执行。
从库数量增加，从库连接上来的/O线程也比较多，主库也要创建同样多的log dump线程来处理复制的请求，对主库资源消耗比较高，同时还受限于主库的网络带宽。
所以在实际使用中，一个主库一般跟2~3个从库(1套数据库，1主2从1备主)，这就是一主多从的MySQL集群结构。
三、同步数据一致性

3.1 主从同步要求

• 读库、写库的数据一致
  
• 写数据必须写到写库
  
• 读数据必须到读库
  

3.2 主从延迟原因、直接表现

网络正常情况下，主从延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差

• 从库的机器性能比主库差
  
• 从库压力大
  
• 大事务的执行
  

主从延迟的直接表现：从库消费中继日志的速度比主库生产binlog的速度慢
3.3 减少主从延迟的方案

• 降低多线程大事务并发的概率，优化业务逻辑
  
• 优化SQL，避免慢SQL，减少批量操作，建议写脚本以update-sleep这样的形式完成
  
• 提高从库机器配置，减少主库写binlog和从库读binlog的效率差
  
• 尽量采用短的链路，也就是主库和从库服务器的距离尽量短，提升端口带宽，减少binlog传输的网络延时
  
• 实时性要求的业务强制走主库，从库只做灾备、备份
  

3.4 数据一致性问题的解决

若操作的数据存储在同一个数据库中，那么对数据进行更新时，可对记录加写锁，这样在读取时就不会发生数据不一致的情况，但从库的作用仅为备份，未起到读写分离、分担主库读压力的作用

读写分离情况下，解决主从同步中数据不一致的问题，就是解决主从之间数据复制方式的问题。若按照数据一致性的从弱到强划分，有3种复制方式：异步复制、半同步复制、组复制
3.4.1 异步复制

3.4.2 半同步复制

3.4.3 组复制

异步复制、半同步复制都无法最终保证数据一致性问题
组复制技术，MRG（MySQL Group Replication），于MySQL在5.7.17推出的一种新的数据复制技术，基于Paxos协议的状态机复制
MGR如何工作?
将多个节点共同组成一个复制组，在执行读写（RW）事务时，需要通过一致性协议层同意，当同意节点数量大于(N/2+1）时才可进行提交，针对只读（RO）事务则不需要组内同意，直接COMMIT即可
在一个复制组内有多个节点组成，它们各自维护了自己的数据副本，并且在一致性协议层实现了原子消息和全局有序消息，从而保证组内数据一致性

参考：
MySQL面试题（最全、超详细）—— sql优化经验、并发事务问题、隔离级别、MVCC、MySQL主从同步
MySQL进阶（日志）——MySQL的日志 & bin log (归档日志) & 事务日志redo log(重做日志) & undo log(回滚日志)
MySQL面试资料

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！