主从同步
Last updated
Last updated
主库上的数据发生变化时，该事件变化会按顺序写入 binlog 中。从库连接到主库时，主库会开启 binlog dump 线程。当 master 的 binlog 发生变化的时候，binlog dump 线程会将相应的 binlog 内容推给 slave 。具体流程如下：
协调者准备阶段 (Prepare Phase)
告诉引擎做 prepare，InnoDB更改事务状态，并将 redo log 刷入磁盘
协调者提交阶段 (Commit Phase)
记录协调者日志，即 binlog 日志
告诉引擎做 commit
从库生成两个线程，一个I/O线程，一个SQL线程
I/O 线程接收主库的 binlog，并转发写到 relay log（中继日志） 文件中
SQL 线程读取 relay log 文件中的日志，并解析成具体操作，来实现主从的操作一致，从而最终数据一致
首先， MySQL 的复制是"推"的，而不是"拉"的。
"拉"是指 MySQL 的备库不断的循环询问主库是否有数据更新，这种方式资源消耗多，并且效率低。
"推"是指 MySQL 的主库在自己有数据更新的时候推送这个变更给备库，这种方式只有在数据有变更的时候才会发生交互，资源消耗少。如果你是程序员出身，你一定会选择推的方式。
那么 MySQL 具体是怎么推的列，实际上 slave 在 master 申请同步数据变更记录的时候，需要指定从主库 binlog 的哪个文件 ( MASTER_LOG_FILE ) 的具体多少个字节偏移位置 ( MASTER_LOG_POS ) 。对应的，主库会启动一个 binlog dump 线程，将变更的记录从这个位置开始一条一条的发给备库。备库一直监听主库过来的变更，接收到一条，才会在本地应用这个数据变更。
1. 异步复制
MySQL 默认的同步方式。master 将事件写入 binlog，提交事务，自身并不关心 slave 是否接收是否处理
缺点：不能保证所有事务都被所有 slave 接收，弱一致性
2. 同步复制
master 会等待所有 slave 的 ack (slave 写完 relay log)，才会返回客户端事务执行完毕信息
缺点：master 写入性能变差，一般 cluster 内部才用
3. 半同步复制
master 会等待至少一个 slave 回应后提交
当半同步复制发生超时时（由参数可配置时长），会暂时关闭半同步复制，转而使用异步复制（？为什么不直接用异步
缺点：造成了至少一个 TCP/IP 往返时长的延时
主库宕机时，客户端可能会重试，导致从库执行2次
针对这个问题，MySQL 5.7 引入了一种新的半同步方案：Loss-Less半同步复制
这种方案里 Waiting Slave dump 被调整到 Storage Commit 之前。
在 MySQL 5.6 版本之前，slave 服务器上有两个线程 I/O线程和 SQL线程。I/O线程负责接收二进制日志，SQL线程进行回放。
MySQL 5.6 后，可以开启并行复制功能，使用多个 worker 执行回放。支持 2 种并行策略：
按库并行: 将 SQL 按数据库分组并行执行。主库上存在多个DB时才实用
组提交优化：将 commit_id 相同的分为一组，不同 commit_id 之间可以并行
先来看下导致主从延迟的时间点：
主库 A 执行完成一个事务，写入 binlog，该时刻记为 T1
传给从库 B，从库接收
完这个 binlog 的时刻记为 T2
从库 B 执行完这个事务，该时刻记为 T3
那么所谓主从延迟的时间差就是 T3 - T1。主从延迟大的原因可能如下：
网络延迟、堵塞
尽量采用短的链路、带宽，比如同城多机房架构
从库回放慢
从库性能差
从库读的流量大，导致 CPU 压力大
事务 / DDL 执行时间较长。当事务执行时间较长，从库再做一遍的耗时也会较长，期间主从数据就会不一致。
主库可以有多个线程并发写，而从库只有一个 SQL 线程执行 relay log。主库写压力较大时，从库执行起来会更慢。
MySQL 5.6 后可以开启并发同步优化
可以通过命令查看主从同步延时：
Seconds_Behind_Master 为 0 并不一定是主从没有延时，也可能是主的 Binlog dump 线程挂了。作为监听的一方，从库一直没有收到任何变更，它会认为主库上长时间没有任何变更，导致没有变更数据推送过来。
从库是无法判断主库上对应的 Binlog dump 线程 到底是意外终止了，还是长时间没有任何数据变更的。所以，对这两种情况来说，备库都显示为正常。
当然， MySQL 会尽量避免这种情况。比如：
在 Binlog dump 被 kill 掉时通知备库 线程 被 kill 掉了。（但这个消息有可能由于网络堵塞无法发送到从库）
备库如果长时间没有收到从主库过来的变更，它会每隔一段时间重连主库。（默认配置是1小时，这个可以配置短点）
MySQL 从 5.7 开始支持多主，但这样很难保证数据的一致性（比如向两主分别写入不同的数据，产生的自增ID可能是冲突的），一般情况下现在都不会这么用多主。
解决方案：
在多主之上加一层，这层写扩散给多主，保证多主写入一样的数据
一个做真实主机，其余做备机，仍然采用主从同步的方式。主机故障时才将备机提升为主。
如何保证主从同步？
使用【异步、半同步、同步】三种中的同步方式
在数据库之上加一层，监控从节点延时。延时过高时路由到主节点
参考
