MySQL的主从复制原理详解
# 一、简介
MySQL主从复制是指将数据从一个MySQL主服务器（主节点）复制到一个或多个MySQL从服务器(从节点)
# 二、主从复制原理
MySQL服务的主从架构一般都是通过binlog日志文件来进行的。
1、主服务上打开binlog记录每一步的数据库操作
2、从服务上会有一个IO线程，负责跟主服务建立一个TCP连接，请求主服务将binlog传输过来
3、主库上会有一个IO dump线程，负责通过这个TCP连接把Binlog日志传输给从库的IO线程
4、从服务的IO线程会把读取到的binlog日志数据写入自己的relay日志文件中
5、从服务上另外一个SQL线程会读取relay日志里的内容，进行操作重演，达到还原数据的目的
主从同步事件binlog模式有3种形式：statement、row、mixed。
- statement： 会将对数据库操作的 sql 语句写入到 binlog 中。
- row： 会将每一条数据的变化写入到 binlog 中。
- mixed： statement 与 row 的混合。MySQL 决定什么时候写 statement 格式的，什么时候写 row 格式的 binlog
# 三、主从复制延迟如何处理？
# 3.1、主从复制延迟排查方式
使用命令SHOW SLAVE STATUS可以查看主从同步是否存在延迟：
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.0.1
Master_User: repl_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000003
Read_Master_Log_Pos: 12345678
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 12345678
Relay_Master_Log_File: mysql-bin.000003
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
.......
Seconds_Behind_Master: 0
.......
1 row in set (0.00 sec)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
重点需要观察三个参数：
- Slave_IO_Running：从服务器的I/O线程是否正在运行。
- Slave_SQL_Running：从服务器的SQL线程是否正在运行。
- Seconds_Behind_Master：从服务器与主服务器之间的复制延迟时间
# 3.2、可能造成延迟的原因
- 从库所在机器的性能要比主库性能差
- 从库的压力较大，即从库承受了大量的请求
- 从库的并行复制能力
可选的解决方案：
- 半同步复制
- 一主多从，分摊从库压力
- 强制走主库方案（强一致性）
- 并行复制 — 解决从库复制延迟的问题
MySQL 5.6 版本的并行复制策略
# 四、其它
# 4.1、什么是半同步复制？
MySQL主从集群默认采用的是一种异步复制的机制，有可能会丢数据，因此引入了半同步复制机制来保证数据安全
半同步复制机制是一种介于异步复制和全同步复制之前的机制。主库在执行完客 户端提交的事务后，并不是立即返回客户端响应，而是等待至少一个从库接收并写 到relay log中，才会返回给客户端。
MySQL在等待确认时，默认会等10秒，如果超 过10秒没有收到ack，就会降级成为异步复制
MySQL 5.5版本引入
# 4.2、什么是GTID同步集群？
GTID的本质也是基于Binlog来实现主从同步，只是他会基于一个全局的事务ID来标识同步进度。
- master更新数据时，会在事务前产生GTID，一同记录到binlog日志中
- slave端的i/o 线程将变更的binlog，写入到本地的relay log中
- sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录
- 如果有记录，说明该GTID的事务已经执行，slave会忽略
- 如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog
MySQL5.6版本引入