日常工作中,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/ref…
- https://dev.mysql.com/doc/int…