日常工作中，MySQL 数据库是必不可少的存储，其中读写拆散根本是标配，而这背地须要 MySQL 开启主从同步，造成一主一从、或一主多从的架构，把握主从同步的原理和晓得如何理论利用，是一个架构师的必备技能。楼主将在本文做总结，看这一篇就够了。

1、主从同步原理

主从同步架构图（异步同步）

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

主从同步流程（异步同步）

1. 主库把数据变更写入 binlog 文件
2. 从库 I / O 线程发动 dump 申请
3. 主库 I / O 线程推送 binlog 至从库
4. 从库 I / O 线程写入本地的 relay log 文件（与 binlog 格局一样）
5. 从库 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。

主从同步流程（半同步）

1. 从库在连贯主库时，表明本人反对半同步复制
2. 主库也需反对半同步复制，主库 commit 事务前会阻塞期待至多一个从库写入 relay log 的 ack，直至超时
3. 如果阻塞期待超时，则主库长期切换回异步同步模式，当至多一个从库的半同步追上进度时，主库再切换至半同步模式

半同步实用场景

高可用备份：半同步复制，可确保从库与主库的一致性，当主库产生故障时，切换到从库不会失落数据。为了保障稳定性（不因半同步慢而连累主库），个别不承当业务流量、尽可能快地 ack，只用于同步备份。

2、主从同步利用场景

一般场景：线上从库异步同步，高可用备份半同步

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

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

参考：mysql 官网文档

• https://dev.mysql.com/doc/ref…
• https://dev.mysql.com/doc/int…