数据库技术:MySQL主从同步原理及应用

目录1、主从同步原理主从同步架构图(异步同步)这是最常见的主从同步架构主从同步流程(异步同步) 主库把数据变更写入binlog文件 从库i/o线程发起dump请求 主库i/o线程推送

目录

    MySQL主从同步原理及应用

    1、主从同步原理

    主从同步架构图(异步同步)

    这是最常见的主从同步架构

    MySQL主从同步原理及应用

    主从同步流程(异步同步)

    • 主库把数据变更写入binlog文件
    • 从库i/o线程发起dump请求
    • 主库i/o线程推送binlog至从库
    • 从库i/o线程写入本地的relay log文件(与binlog格式一样)
    • 从库sql线程读取relay log并重新串行执行一遍,得到与主库相同的数据

    什么是binlog?

    主库每提交一次事务,都会把数据变更,记录到一个二进制文件中,这个二进制文件就叫binlog。需注意:只有写操作才会记录至binlog,只读操作是不会的(如selectshow语句)。

    binlog的3种格式

    statement格式:binlog记录的是实际执行的sql语句
    row格式:binlog记录的是变化前后的数据(涉及所有列),形如update table_a set col1=value1, col2=value2 ... where col1=condition1 and col2=condition2 ...
    mixed格式:默认选择statement格式,只在需要时改用row格式

    binlog格式对比

    • statement级别:优点是binlog文件小,缺点是主库的慢sql也会在从库上再出现一次,一些依赖环境或上下文的函数可能会产生不一致的数据
    • row级别:缺点是文件大(一条语句如果涉及多行,会放大n倍),优点是无上述慢sql问题,不依赖环境或上下文
    • 为了获取前后变化数据,canal建议使用row级别

    主从同步的2种方式

    • 异步同步:默认方式,可能会导致主从切换时数据丢失。因为主库是否commit与主从同步流程无关,也不感知。
    • 半同步:高可用方案,较新mysql版本支持,需要至少1个从库(默认1,具体数量可指定)对写入relay log进行ack,主库才会commit并把结果返回client

    主从同步流程(半同步)

    • 从库在连接主库时,表明自己支持半同步复制
    • 主库也需支持半同步复制,主库commit事务前会阻塞等待至少一个从库写入relay logack,直至超时
    • 如果阻塞等待超时,则主库临时切换回异步同步模式,当至少一个从库的半同步追上进度时,主库再切换至半同步模式

    半同步适用场景

    高可用备份:半同步复制,可确保从库与主库的一致性,当主库发生故障时,切换到从库不会丢失数据。为了保证稳定性(不因半同步慢而拖累主库),一般不承担业务流量、尽可能快地ack,只用于同步备份。

    2、主从同步应用场景

    普通场景:线上从库异步同步,高可用备份半同步

    MySQL主从同步原理及应用

    对一致性要求较高的大数据取数需求

    大数据取数可能导致从库cpu使用率飙升、ack变慢,可设置半同步所需ack数量为1,正常情况下高可用备份能很快ack,于是主库会commit并返回,而大数据取数复制慢一些也无所谓。这样就不会因为大数据取数ack慢而影响主库和业务了。

    MySQL主从同步原理及应用

    到此这篇关于mysql主从同步原理及应用的文章就介绍到这了,更多相关mysql主从同步原理及应用内容请搜索<猴子技术宅>以前的文章或继续浏览下面的相关文章希望大家以后多多支持<猴子技术宅>!

    需要了解更多数据库技术:MySQL主从同步原理及应用,都可以关注数据库技术分享栏目—猴子技术宅(www.ssfiction.com)

    本文来自网络收集,不代表猴子技术宅立场,如涉及侵权请点击右边联系管理员删除。

    如若转载,请注明出处:https://www.ssfiction.com/sqljc/840085.html

    发表评论

    邮箱地址不会被公开。 必填项已用*标注