MySQL 主从复制的原理
MySQL 的主从复制依赖于 binlog ,也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。复制的过程就是将 binlog 中的数据从主库传输到从库上。这个过程一般是异步的
-
写入 Binlog:主库写 binlog 日志,提交事务,并更新本地存储数据。
-
同步 Binlog:把 binlog 复制到所有从库上,每个从库把 binlog 写到暂存日志中。
-
回放 Binlog:回放 binlog,并更新存储数据。
这就是“一主多从”的部署方式,你在垂直电商项目中可以用该方式抵御较高的并发读流量。另外,从库也可以作为一个备库,以避免主库故障导致的数据丢失。
MySQL 一主多从
是不是只要多增加几台从库,就可以抗住大促的并发读请求了?
从库数量增加,从库连接上来的 I/O 线程也比较多,主库也要创建同样多的 log dump 线程来处理复制的请求,对主库资源消耗比较高,同时还受限于主库的网络带宽。所以在实际使用中,一个主库一般跟 2~3 个从库(1 套数据库,1 主 2 从 1 备主),这就是一主多从的 MySQL 集群结构。
MySQL 主从复制过程也能发现,MySQL 默认是异步模式:MySQL 主库提交事务的线程并不会等待 binlog 同步到各从库,就返回客户端结果。这种模式一旦主库宕机,数据就会发生丢失。
-
同步复制:事务线程要等待所有从库的复制成功响应。
-
异步复制:事务线程完全不等待从库的复制成功响应。
-
半同步复制:MySQL 5.7 版本之后增加的一种复制方式,介于两者之间,事务线程不用等待所有的从库复制成功响应,只要一部分复制成功响应回来就行,比如一主二从的集群,只要数据成功复制到任意一个从库上,主库的事务线程就可以返回给客户端。
这种半同步复制的方式,兼顾了异步复制和同步复制的优点,即使出现主库宕机,至少还有一个从库有最新的数据,不存在数据丢失的风险。
从架构上解决主从复制延迟
-
使用数据冗余
-
使用缓存解决
-
直接查询主库
几乎所有的存储系统或数据库,基本都用了这样一套方法来解决数据复制和备份恢复等问题。
标签:主库,binlog,读多,复制,线程,MySQL,写少,从库 From: https://www.cnblogs.com/jiaozg/p/17214987.html