MySQL 中主从复制的原理是什么,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。其实很简单,就是基于主从复制架构,简单来说,就搞一个主库,挂多个从库,然后我们就单单只是写主库,然后主库会自动把数据给同步到从库上去。主库将变更写入 binlog 日志,然后从库连接到主库之后,从库有一个 IO 线程,将主库的 binlog 日志拷贝到自己本地,写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog,然后执行 binlog 日志中的内容,也就是在自己本地再次执行一遍 SQL,这样就可以保证自己跟主库的数据是一样的。这里有一个非常重要的一点,就是从库同步主库数据的过程是串行化的,也就是说主库上并行的操作,在从库上会串行执行。所以这就是一个非常重要的点了,由于从库从主库拷贝日志以及串行执行 SQL 的特点,在高并发场景下,从库的数据一定会比主库慢一些,是有延时的。所以经常出现,刚写入主库的数据可能是读不到的,要过几十毫秒,甚至几百毫秒才能读取到。而且这里还有另外一个问题,就是如果主库突然宕机,然后恰好数据还没同步到从库,那么有些数据可能在从库上是没有的,有些数据可能就丢失了。所以 MySQL 实际上在这一块有两个机制,一个是半同步复制,用来解决主库数据丢失问题;一个是并行复制,用来解决主从同步延时问题。这个所谓半同步复制,也叫semi-sync
复制,指的就是主库写入 binlog 日志之后,就会将强制此时立即将数据同步到从库,从库将日志写入自己本地的 relay log 香港云主机 之后,接着会返回一个 ack 给主库,主库接收到至少一个从库的 ack 之后才会认为写操作完成了。所谓并行复制,指的是从库开启多个线程,并行读取 relay log 中不同库的日志,然后并行重放不同库的日志,这是库级别的并行。以前线上确实处理过因为主从同步延时问题而导致的线上的 bug,属于小型的生产事故。是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据,再把它查出来,然后更新这条数据。在生产环境高峰期,写并发达到了 2000/s,这个时候,主从复制延时大概是在小几十毫秒。线上会发现,每天总有那么一些数据,我们期望更新一些重要的数据状态,但在高峰期时候却没更新。用户跟客服反馈,而客服就会反馈给我们。我们通过 MySQL 命令:查看Seconds_Behind_Master
,可以看到从库复制主库的数据落后了几 ms。一般来说,如果主从延迟较为严重,有以下解决方案:分库,将一个主库拆分为多个主库,每个主库的写并发就减少了几倍,此时主从延迟可以忽略不计。打开 MySQL 支持的并行复制,多个库并行复制。如果说某个库的写入并发就是特别高,单库写并发达到了 2000/s,并行复制还是没意义。重写代码,写代码的同学,要慎重,插入数据时立马查询可能查不到。如果确实是存在必须先插入,立马要求就查询到,然后立马就要反过来执行一些操作,对这个查询设置直连主库。不推荐这种方法,你要是这么搞,读写分离的意义就丧失了。分布式事务系列:Spring 分布式事务实现概览
REST微服务的分布式事务实现-使用Spring Cloud的fallback模式
Spring的分布式事务实现-使用和不使用XA
REST微服务的分布式事务实现-基于消息中间件
REST微服务的分布式事务实现-分布式系统、事务以及JTA介绍
某宝布式事务架构设计
大白话聊聊分布式事务
分布式事务解决方案
消息队列系列:为什么使用消息队列?
如何保证消息队列的高可用?
如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性?
如何保证消息的可靠性传输?或者说,如何处理消息丢失的问题?
如何保证消息的顺序性?
如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?
分库分表系列:为什么要分库分表?
如何设计才可以让系统从未分库分表动态切换到分库分表上?
如何设计可以动态扩容缩容的分库分表方案?
分库分表之后,id 主键如何处理?关于MySQL 中主从复制的原理是什么问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注开发云行业资讯频道了解更多相关知识。
小编给大家分享一下Win10升级后中英文输入法无法切换怎么办,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!1、打开计算机管理,Windows7系统中在桌面的计算机图标右键菜单中可找到…
免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。