MySQL主从复制 —— 作用、原理、数据一致性，异步复制、半同步复制、组复
文章目录一、作用
二、原理
三、同步数据一致性
[*]3.1 主从同步要求
[*]3.2 主从延伸缘故原由、直接表现
[*]3.3 减少主从延伸的方案
[*]3.4 数据一致性问题的解决
[*]3.4.1 异步复制
[*]3.4.2 半同步复制
[*]3.4.3 组复制
https://img2024.cnblogs.com/blog/3047087/202502/3047087-20250206223759638-1385304896.png
MySQL主从复制的核心就是二进制日志binlog
二进制日志（BINLOG）记载了全部的 DDL（数据界说语言，创建库、表）语句和 DML（数据利用语言，增删改）语句，但不包罗数据查询（SELECT、SHOW）语句。
一、作用
[*]读写分离
[*]数据备份
[*]高可用性
二、原理
实际上主从同步是基于binlog进行数据同步的。在主从复制过程中，会基于3个线程来操纵，一个主库线程、两个从库线程
https://img2024.cnblogs.com/blog/3047087/202502/3047087-20250206223812872-2100079520.png
[*]二进制日志转储线程（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复制时异步且串行化的，重启后从接入点开始复制。
https://img2024.cnblogs.com/blog/3047087/202502/3047087-20250206223828912-1297680236.png
https://img2024.cnblogs.com/blog/3047087/202502/3047087-20250206223837238-312604679.jpg
具体详细过程如下：
[*]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 数据一致性问题的解决
若操纵的数据存储在同一个数据库中，那么对数据进行更新时，可对记载加写锁，这样在读取时就不会发生数据不一致的情况，但从库的作用仅为备份，未起到读写分离、分担主库读压力的作用
https://img2024.cnblogs.com/blog/3047087/202502/3047087-20250206223854691-1542527961.png
读写分离情况下，解决主从同步中数据不一致的问题，就是解决主从之间数据复制方式的问题。若按照数据一致性的从弱到强分别，有3种复制方式：异步复制、半同步复制、组复制
3.4.1 异步复制
https://img2024.cnblogs.com/blog/3047087/202502/3047087-20250206223906043-1664165826.png
3.4.2 半同步复制
https://img2024.cnblogs.com/blog/3047087/202502/3047087-20250206223915932-1387052277.png
3.4.3 组复制
异步复制、半同步复制都无法最终保证数据一致性问题
组复制技术，MRG（MySQL Group Replication），于MySQL在5.7.17推出的一种新的数据复制技术，基于Paxos协议的状态机复制
MGR如何工作?
将多个节点共同组成一个复制组，在执行读写（RW）事务时，须要通过一致性协议层同意，当同意节点数量大于(N/2+1）时才可进行提交，针对只读（RO）事务则不须要组内同意，直接COMMIT即可
在一个复制组内有多个节点组成，它们各自维护了自己的数据副本，并且在一致性协议层实现了原子消息和全局有序消息，从而保证组内数据一致性
https://img2024.cnblogs.com/blog/3047087/202502/3047087-20250206223928417-2042419343.png
参考：
MySQL口试题（最全、超详细）—— sql优化经验、并发事务问题、隔离级别、MVCC、MySQL主从同步
MySQL进阶（日志）——MySQL的日志 & bin log (归档日志) & 事务日志redo log(重做日志) & undo log(回滚日志)
MySQL口试资料
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]