主从概述

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

常见主从架构

单向主从模式

双向主从模式

级联主从

一主多从

多主一从

主从复制功能

利用MySQL主从复制的功能，我们可以实时灾备，让从库随时接管有故障的主库。还可以让从库分担主库的读压力，做读写分离，提供查询服务。并且可以让从库做一些特殊SQL的统计任务。最后也可以利用从库做备份来减少对公司现有业务的影响，以及利用从库来完成MySQL平滑的版本升级操作。

主从复制原理

主从复制的原理：主从复制过程中涉及几个线程（thread）。主服务器有一个工作线程I/O dump thread，从服务器有两个工作线程，一个是I/O thread，另一个是SQL thread。
主库把外界接收的SQL请求记录到自己的binlog日志中，从库的I/O thread去请求主库的binlog日志，并将得到的binlog日志写到自己的Relay log (中继日志）文件中。然后在从库上重做应用中继日志中的SQL语句。主库通过I/O dump thread给从库I/O thread传送binlog日志。主从原理如下图：

常见主从复制类型

异步复制

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

半同步复制

MySQL数据库复制默认的方式是异步复制，但异步复制的不足之处就在于，当主库把event写入二进制日志之后，并不知道从库是否已经接收并应用了。在异步模式下的复制，如果主库崩溃，很有可能在主库中己经提交的事务，并没有传到任何一台从库机器上。在高可用集群架构下做主备切换，就会造成新的主库丢失数据的现象。
MySQL 5.5版本之后引入了半同步复制功能，主从服务器必须同时安装半同步复制插件，才能开启该复制功能。在该功能下，确保从库接收完主库传递过来的binlog内容己经写入到自己的relay log里面了，才会通知主库上面的等待线程，该操作完毕。如果等待超时，超过rpl_semi_sync_master_timeout参数设置的时间，则关闭半同步复制，并自动转换为异步复制模式，直到至少有一台从库通知主库己经接收到binlog信息了为止。
半同步复制提升了主从之间数据的一致性，让复制更加安全可靠。
在MySQL 5.7版本中又增加了rpl_semi_sync_master_wait_point参数，用来控制半同步模式下主库在返回给session事务成功之前的事务提交方式。
该参数有两个值：
(1) AFTER_COMMIT。
该值是MySQL 5.6版本的默认值，含义为：主库将每个事务写入binlog,并传递给从库，刷新到中继日志中，同时主库提交事务。之后主库开始等待从库的反馈，只有收到从库的回复之后，master才将“commit 0K”的结果反馈给客户端。
(2) AFTER_SYNC。
该值是MySQL 5.7版本之后新增的，也是MySQL 5.7默认的半同步复制方式。含义为：主库将每个事务写入binlog，并传递给从库，刷新到中继日志中，主库开始等待从库的反馈，接收到从库的回复之后，再提交事务并且返回“commit 0K”结果给客户端。
在after_sync模式下，即使主库宕机，所有在主库上己经提交的事务都能保证己经同步到从库的中继日志中，不会丢任何数据。
半同步复制的搭建很简单，它基于异步复制的基础上，安装半同步复制插件就可以了。 

GTID复制原理

GTID又叫全局事务ID (Global Transaction ID)，是一个己提交事务的编号，并且是一个全局唯一的编号。MySQL 5.6版本之后在主从复制类型上新增了GTID复制。
GTID 是由 server uuid 和事务 id 组成的，即 GTID = server_uuid:transaction_id。server_uuid
是在数据库启动过程中自动生成的，每台机器的server-uuid不一样。uuid存放在数据目录的auto.cnf文件下。而transaction_id就是事务提交时由系统顺序分配的一个不会重复的序列号。

GTID存在的价值：
(1)GTID使用master_auto_positinotallow=1代替了基于binlog和position号的主从复制搭建方式，更便于主从复制的搭建。
(2)GTID可以知道事务在最开始是在哪个实例上提交的。
(3)GTID方便实现主从之间的failover，再也不用不断地去找position和binlog了。

主从复制中GTID的管理与维护：
GTID带来最方便的一点就是主从复制的搭建过程了。它跟异步复制、半同步复制类似， 只不过不再利用传统复制模式的binlog文件和position号而是在从库“change master to”时 使用master_auto_positinotallow=l的方式进行搭建，这就让操作变得更加方便和可靠。

GTID使用中的限制条件:
GTID复制是针对事务来说的，一个事务只对应一个GTID,好多的限制就在于此。
(1)    不能使用 create table table_name select * from table_name。
(2)    在一个事务中既包含事务表的操作又包含非事务表。
(3)    不支持 CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE 语句操作。
(4)  使用GTID复制从库跳过错误时，不支持执行sql_slave_skip_counter参数的语法。

多源复制

所谓多源复制，就是把多台主库的数据同步到一台从库服务器上，从库会创建通往每个主库的管道。在MySQL5.7之前的版本中，只能实现一主一从、一主多从或者多主多从的复制架构，如果想要实现多主一从的复制，只能使用MariaDB。MySQL 5.7版本己经可以实现多主一从的复制。它的搭建过程支持GTID模式和binlog+position方式。

多源复制的优势：

(1)可以集中备份，在从库上备份，不会影响线上的数据库正常运行。

(2)节约了购买从库服务器的成本，只需要一个服务器即可。

(3)数据都汇总在一起，方便后期做数据统计。

搭建中的注意事项：

多个主库不能拥有相同的数据库名字，否则就会在从库出现数据覆盖的现象。

一主多从

在主库读取请求压力非常大的场景下，可以通过配置一主多从复制架构实现读写分离，把大量对实时性要求不是特别高的读请求通过负载均衡分布到多个从库上，降低主库的读取压力，如下图所示。

在主库出现异常宕机的情况下，可以把一个从库切换为主库继续提供服务。

级联复制

级联复制也可以理解为多级复制。
一主多从的架构能够解决大部分读请求压力特别大的场景的需求，考虑到MySQL的复制是主库“推送” Binlog日志到从库，主库的I/O压力和网络压力会随着从库的增加而增长（每个从库都会在主库上有一个独立的Binlog Dump线程来发送事件），而多级复制架构解决了一主多从场景下，主库额外的I/O和网络压力。MySQL的多级复制架构如下图所示。

对比一主多从的架构图，多级复制仅仅是在主库Master1复制到从库Slave1、Slave2、Slave3 的中间增加一个二级主库Master2,这样，主库Master1只需要给一个从库Master2“推送”Binlog 日志皆可，减轻主库Master1推送的压力。二级主库Master2再“推送”Binlog日志给从库Slave1、 Slave2、Slave3。
多级复制解决了一主多从场景下，主库的I/O负载和网络压力，当然也有缺点：MySQL 的复制是异步复制，多级复制场景下主库的数据是经历两次复制才到达从库Slave1、Slave2、 Slave3的，期间的延时比一主多从复制场景下只经历一次复制的要大。

双主复制

双主复制架构特别适用于DBA做维护等需要主从切换的场景，通过双主复制架构避免了重复搭建从库的麻烦，双主的架构如下图所示。

主库Master1和Master2互为主从，所有Web Client客户端的写请求都访问主库Master1, 而读请求可以选择访问主库Master1或Master2。假如，DBA需要做日常维护操作，为了避免影响服务：
-首先，在Master1库上停止Slave线程（STOP SLAVE),避免后续对Master2库的维护操作被实时复制到Master1库上对服务造成影响；
-其次，在Master2库上停止Slave线程（STOP SLAVE),开始日常维护操作，例如创建索引等；
-然后，在Master2库上完成维护操作之后，打开Master2库上的Slave线程（START SLAVE )，让Master2库的数据和Master1库同步，同步完成后，把应用的读写操作切换到Master2 库上；
-最后，确认Master1库上无应用访问后，打开Master1库的Slave线程(START SLAVE) 即可。
通过双主复制架构能够大大减轻一主多从架构下对主库进行维护带来的额外搭建从库的工作。