架构师必备:MySQL主从同步原理和应用
2023-03-14 09:38:37 时间
日常工作中,MySQL数据库是必不可少的存储,其中读写分离基本是标配,而这背后需要MySQL开启主从同步,形成一主一从、或一主多从的架构,掌握主从同步的原理和知道如何实际应用,是一个架构师的必备技能。楼主将在本文做总结,看这一篇就够了。
1、主从同步原理
主从同步架构图(异步同步)
主从同步流程(异步同步)
- 主库把数据变更写入binlog文件
- 从库I/O线程发起dump请求
- 主库I/O线程推送binlog至从库
- 从库I/O线程写入本地的relay log文件(与binlog格式一样)
- 从库SQL线程读取relay log并重新串行执行一遍,得到与主库相同的数据
什么是binlog?
主库每提交一次事务,都会把数据变更,记录到一个二进制文件中,这个二进制文件就叫binlog。需注意:只有写操作才会记录至binlog,只读操作是不会的(如select、show语句)。
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 log的ack,直至超时
- 如果阻塞等待超时,则主库临时切换回异步同步模式,当至少一个从库的半同步追上进度时,主库再切换至半同步模式
半同步适用场景
高可用备份:半同步复制,可确保从库与主库的一致性,当主库发生故障时,切换到从库不会丢失数据。为了保证稳定性(不因半同步慢而拖累主库),一般不承担业务流量、尽可能快地ack,只用于同步备份。
2、主从同步应用场景
普通场景:线上从库异步同步,高可用备份半同步
对一致性要求较高的大数据取数需求
大数据取数可能导致从库cpu使用率飙升、ack变慢,可设置半同步所需ack数量为1,正常情况下高可用备份能很快ack,于是主库会commit并返回,而大数据取数复制慢一些也无所谓。这样就不会因为大数据取数ack慢而影响主库和业务了。
参考:mysql官方文档
- https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html
- https://dev.mysql.com/doc/internals/en/binary-log-overview.html
相关文章
- SQL查询优化
- MySQL主从复制
- 五个原则下的数据质量建设之道
- 数据虚拟视图定位与智能化实现
- 如何快速搭建常用的数据指标体系
- 如何构建企业级用户画像
- PGG.MHC--人类主要组织相容性复合体基因数据库和分析平台
- Hadoop支持的压缩格式,是否支持split,什么场景下使用,建议收藏
- 数据可视化分析作品:B站up主粉丝数据分析
- 五年经验的前端社招被问:CPU 和 GPU 有什么区别?
- MySQL 的自增主键一定是连续
- 列名是会变的日期,数据更新就出错,怎么办?
- 虹科方案|使用直接连接的阵列创建 SAN
- 杭州亚锐-镭速文件传输系统技术方案
- 从小白到专家 PostgreSQL技术大讲堂 - Part 5:PG数据库结构
- MySQL的system命令显示的是服务端的信息?
- 王喆:"深度"学习计算广告
- SQL速算N日留存
- mysql修改支持utf8mb4字符集编码格式
- 理解mvvm和mvc