MySQL：主从复制原理

1、主从复制概述

MySQL主从复制也可以称为MySQL主从同步，它是构建数据库高可用集群架构的基础。它通过将一台主机的数据复制到其他一台或多台主机上，并重新应用relay log中的SQL语句来实现复制功能。MySQL支持单向、双向、链式级联、异步复制，5.5版本之后加入的半同步复制，5.6版本之后的GTID复制，MySQL5.7的多源复制、并行复制、loss-less复制。

1.1 常见的几种主从架构

1）单向主从模式：Master ——> Slave

2）双向主从模式：Master <====> Master

3）级联主从模式：Master ——> Slave1 ——> Slave2

4）一主多从模式

5）多主一从模式

1.2 主从复制功能

1）实时灾备

2）读写分离

3）高可用

4）从库数据统计

5）从库数据备份

6）平滑升级

1.3 主从复制原理

主从同步过程中主服务器有一个工作线程I/O dump thread，从服务器有两个工作线程I/O thread和SQL thread。

主库把外界接收的SQL请求记录到自己的binlog日志中，从库的I/O thread去请求主库的binlog日志，并将binlog日志写到中继日志中，然后从库重做中继日志的SQL语句。主库通过I/O dump thread给从库I/O thread传送binlog日志。

原理图
![在这里插入图片描述](https://img-blog.csdnimg.cn/20191215105758594.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2tlc2Vuemhhbmc=,size_16,color_FFFFFF,t_70

2、复制原理

2.1 异步复制

异步复制是MySQL默认的复制方式，主库写入binlog日志后即可成功返回客户端，无须等待binlog日志传递给从库的过程，但是一旦主库宕机，就有可能出现丢失数据的情况。

2.2 半同步复制

MySQL默认的复制方式是异步复制，但是当主库宕机，在高可用架构坐准备切换，就会造成新的主库丢失数据的现象。

MySQL5.5版本之后引入了半同步复制，但是主从服务器必须同时安装半同步复制插件。在该功能下，确保从库接收完成主库传递过来的binlog内容已经写入到自己的relay log后才会通知主库上面的等待线程。如果等待超时(超时参数：rpl_semi_sync_master_timeout)，则关闭半同步复制，并自动转换为异步复制模式，直到至少有一台从库通知主库已经接收到binlog信息为止。

半同步复制原理图：

半同步复制提升了主从之间数据的一致性，让复制更加安全可靠，在5.7 版本中又增加了rpl_semi_sync_master_wait_point参数，用来控制半同步模式下主库返回给session事务成功之前的事务提交方式。

该参数有两个值：

1）AFTER_COMMIT：5.6版本的默认值，主库将每个事务写入binlog，并传递给从库，刷新到中继日志中，同时主库提交事务。之后主库开始等待从库的反馈，只有收到从库的回复之后，master才将commit OK的结果反馈给客户端。

2）AFTER_SYNC：5.7版本新增，也是默认的半同步复制方式。主库将每个事务写入binlog并传递给从库，刷新到中继日志中，主库开始等待从库的反馈，接收到从库的回复之后，再提交事务并且返回commit OK结果给客户端。

注意：可以通过rpl_semi_sync_master_wait_for_slave_count参数来控制主库接收多少个从库写事务成功反馈，才返回成功给客户端。生产环境中使用半同步复制方式，当从库出现故障，等待超时的时间又很长，导致主库无法接收从库信息而无法正常写入时，可通过该参数剔除故障从库。另外rpl_semi_sync_master_timeout单位是毫秒，它表示如果主库等待从库回复消息的时间超过该值，就自动切换为异步复制模式，建议调整为很大，禁止向异步复制切换来保证数据复制的安全性。MySQL 5.7默认的半同步复制方式是after_sync模式。

在AFTER_SYNC模式下，即使主库宕机，所有在主库上已经提交的事务都能保证已经同步到从库的中继日志中，不会丢任何数据。

2.3 GTID复制

GTID又叫全局事务ID，是一个以提交事务的编号，并且是一个全局唯一的编号。GTID是由server_uuid和事务id组成的，即GTID=server_uuid:transaction_id。

server_uuid是数据库启动自动生成的，保存在auto.cnf文件下，transaction_id是事务提交时由系统顺序分配的一个不会重复的序列行。

GTID存在的价值：

1）GTID使用master_auto_position=1代替了基于binlog和position号的主从复制方式，更便于主从复制的搭建。

2）GTID可以知道事务在最开始是哪个实例上提交的。

3）GTID方便实现主从之间的failover，无须找position和binlog。

GTID限制条件：

1）不能使用create table table_name select * from table_name。

2）不支持CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE语句操作。

3）不支持sql_slave_skip_counter。