目录
- 1、主从同步原理
- 主从同步架构图（异步同步）
- 主从同步流程（异步同步）
- 什么是binlog？
- binlog的3种格式
- binlog格式对比
- 主从同步的2种方式
- 主从同步流程（半同步）
- 半同步适用场景
- 2、主从同步应用场景
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主从同步原理及应用的文章就介绍到这了,更多相关MySQL主从同步原理及应用内容请搜索NICE源码以前的文章或继续浏览下面的相关文章希望大家以后多多支持NICE源码！
