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

农民  金牌会员 | 2025-2-12 16:32:15 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题

主题 871|帖子 871|积分 2613

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

  • 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口试资料

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

农民

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表