复制的三种类型

全同步复制
在主节点上写入的数据，在从服务器上都同步完了以后（SQL执行重写完成）才会给客户端返回成功消息，相对来说比较安全，比较靠谱。但是返回信息的时间比较慢
异步复制
通常默认都是异步，即主库执行完Commit后，在主库写入Binlog日志后即可成功返回客户端，无需等Binlog日志传送给从库，一旦主库宕机，有可能会丢失日志。
半同步复制
主库端当一个事务成功提交后，并不及时反馈给前端用户，该线程会被临时block，等待由从库端返回确认该条事务也同时成功写入到relay log中的receipt（回执确认），这时主库线程才返回给当前session告知操作完成，半同步复制并不关心在从库一端该事务是否都被执行并被提交完成。

半同步复制操作

需要安装插件

静态：.c
动态：.so

主库

安装插件
install plugin rpl_semi_sync_master soname "semisync_master.so";

查看
show variables like "rpl_semi_sync_master%";

开启半同步复制
set global rpl_semi_sync_master_enabled=ON;

从库

安装插件
install plugin rpl_semi_sync_slave soname "semisync_slave.so";

查看
show variables like "rpl_semi_sync_slave%";

开启
set global rpl_semi_sync_slave_enabled=1;

从库查看一下主从复制是否开启，并重启IO线程
show slave status;
stop slave io_thread;
start slave io_thread;

查看一下主库的同步信息

在已经同步好的表中插入一条数据后
show status like "rpl%";

下面实验一个半同步模式异步复制的处理方式

关闭从库的IO线程
stop slave io_thread;

再次插入一条数据，发现等待10秒之后才会成功插入，原因：开启了半同步复制，设置等待时间为10秒，10秒过后还没有同步成功，则此事务切换为异步

此时多出一条异步复制处理的事务

当从库网络良好时，再次恢复为半同步复制
start slave io_thread;

mysql5.7支持的增强半同步复制

实现：show variables like "rpl_semi_sync_master%";

mysql5.7默认为AFTER_SYNC（增强半同步复制），将时间点改为：AFTER_COMMIT，则会改成半同步复制

架构总结：

三种复制模式

1、半同步和增强半同步复制都要从库进行IO线程接收数据并写入中继日志之后才继续进行
2、半同步和增强半同步的区别是：半同步从库是在bin-log写完并commit之前不进行从库同步，而是在commit之后写入到binlog日志之后才进行同步，缺点在于commit传送之后如果在进行同步的过程中从库宕机会导致数据不一致，sync增强半同步模式可以在主库写入数据时同时写入到从库，从库传完之后，主库才会commit，返回给前端应用

基于GTID复制

简介

5.6.5开始支持的

MySQL从5.6版本开始引入了全局事务标识符（Global Transaction Identifiers, GTID）的概念，为每个事务都分配一个唯一的标识符。GTID以事务为单位管理复制，不再需要靠log_file和log_pos来定位复制位置，在主从切换、故障恢复时更加简单。

操作

查看GTID是否启动，并临时启动
show variables like "gtid_mode";

set global gtid_mode=ON_PERMISSIVE;

查看gtid事务
可以使用
show master status;

测试gtid是否在进行同步
select * from mysql.gtid_executed;

默认正在被写入的bin-log不会被保存到文件中
如果切换到下一个binlog日志，上一个日志会被显示出来
flush logs;
select * from mysql.gtid_executed;

增加binlog日志，插入数据

重做基于GTID的主从复制
stop slave;
reset slave all;
重置中继日志（包括内存中的记录（show slave status不会出现），如果不加all，配置信息会保存在内存中）

从库也需要开启GTID
set global gtid_mode=ON_PERMISSIVE;

从库指向主库
change master to master_user="slave",master_password="123",master_host="192.168.1.10",master_auto_position=1;

开启slave
start slave;
出现报错：show slave status;The replication receiver thread cannot start in AUTO_POSITION mode: the master has GTID_MODE = OFF instead of ON.

说明必须放入到配置文件中（主从库）
vim /etc/my.cnf
[mysqld]下写入

强制保持GTID参数一致
重启mysql服务

show variables like "gtid_mode";

重启之后需要重新指定
主库
show master status;
从库
change master to master_user="slave",master_password="123",master_host="192.168.1.10",master_auto_position=1;
start slave;
show slave status\G

GTID总结：

首先配主从复制

vim /etc/my.cnf
额外加入

主库创建一条数据并刷新binlog日志
create database abc;
flush logs;
show master status;

select * from mysql.gtid_executed;

重启之后需要重新指定主从关系

主库
grant replication slave on *.* to slave@'192.168.1.%' identified by '123';
show master status;

从库重新接受授权
change master to master_user="slave",master_password="123",master_host="192.168.1.10",master_auto_position=1;
start slave;
show slave status\G