MySQL主从复制（GTID模式）
https://www.cnblogs.com/kindnull/p/9051358.html
https://www.jianshu.com/p/35875288570c
当mysql更新到5.7之后GTID（全局事务标示符）就比较完善了。
1.为什么要主从复制？
没有为什么，开心就好，等你主机服务器突然宕机sql无法启动的时候你就明白了，等等
2.什么是GTID？
全局事务ID，保证为每一个在主数据库上提交的事务在复制集群中可以生成一个唯一的ID，GTID包括两个值，一个是serveruuid代表每个库的id值，并且唯一性，另外一个是transaction_id事务id，代表已执行事务的id，且主库与从库1:1相等，
3.GTID与基于二进制日志复制的区别？
首先两者都是基于bin_log日志复制的，二进制复制是从服务器告诉主服务器从哪个二进制日志偏移量进行增量同步，如果指定错误就会遗漏或者重复，GTID从库把已执行事务的GTID值发送给主库，主库对比日志之后把未执行的GTID值传给从库，从而更新从库,同一个事务只在指定的从库执行一次，不会发生重复执行。
4.GTID主从复制的配置要求？
mysql版本一定要>=5.7,5.6的也行只要不怕突然出bug就行，而且mysql更新到5.7之后最重要的是，可以一从多主了，想想是不是很刺激嘿嘿。
开启GTID后有如下限制：
不允许在同一个事务内对事务表和非事务进行DML操作，例如在同一个事务内先update innodb表，然后update myisam表 就会产生两个GTID；不允许create table… select语句等等，其他的百度。一般正常操作不会影响。
GTID复制原理：
基于GTID的复制是MySQL 5.6后新增的复制方式.
GTID (global transaction identifier) 即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID.
在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致.
而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可以保证同一个事务只在指定的从库执行一次.
GTID是由server_uuid和事物id组成，格式为：GTID=server_uuid:transaction_id。server_uuid是在数据库启动过程中自动生成，每台机器的server-uuid不一样。uuid存放在数据目录的auto.conf文件中，而transaction_id就是事务提交时系统顺序分配的一个不会重复的序列号。
GTID的好处：
（1）GTID使用master_auto_position=1代替了binlog和position号的主从复制搭建方式，相比binlog和position方式更容易搭建主从复制。
（2）GTID方便实现主从之间的failover，不用一步一步的去查找position和binlog文件。
GTID模式复制搭建过程中注意事项：
主从需要设置如下参数（一般直接在配置文件/etc/my.cnf下直接添加）：
a、主库配置：
gtid_mode = on 启动GITD模式
log-slave-updates = on 更新事务修改日志，5.7之后可以省略
enforce-gtid-consistency = on 开启强制GTID一致性保证事务安全
log_bin=on
master_info_repository =TABLE
relay_log_info_repository = TABLE 可选项（先看看是否已配置）
server-id = 1 主库server-id 和之前的serveruuid是两码事，别搞混了
binlog_format=row （查看笔记中MYSQL中BINLOG_FORMAT的三种模式）
b、从库配置：
server-id = 2 主库server-id 和之前的serveruuid是两码事，别搞混了
gtid_mode = on 启动GITD模式
relay_log = /usr/local/mysql/sql_log/mysql-relay-bin 路径随意改变
log-slave-updates = on 更新事务修改日志，5.7之后可以省略
enforce-gtid-consistency = on 开启强制GTID一致性保证事务安全
read_only=on
master_info_repository =TABLE
relay_log_info_repository = TABLE可选项
主库上操作：
root@db 15:10: [mysql]>create user 'repluser'@'192.168.112.%' identified by 'repluser123'; root@db 15:10: [mysql]> grant replication slave on *.* to 'repluser'@'192.168.112.%';
主库导出数据库脚本all.sql
mysqldump -uroot -hlocalhost -p --single-transaction --master-data=2 -A >all.sql
从库上操作：
将主库上导出的all.sql脚本上传到从库，然后导入从库
mysql -uroot -hlocalhost -p <all.sql
如果出现如下错误：
ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
则在从库命令行下执行：reset master
root@db 15:20: [mysql]> reset master;
跟普通模式一样，执行change master语句，只不过其中的binlog和position换成master_auto_position=1
CHANGE MASTER TO MASTER_HOST='192.168.112.220', MASTER_USER='repluser', MASTER_PASSWORD='repluser123', MASTER_PORT=3306, MASTER_AUTO_POSITION=1;
启动slave复制服务
start slave;
查看主从复制状态：
root@db 15:23: [mysql]> show slave status\G;
由上可知：
Slave_IO_Running: Yes
lave_SQL_Running: Yes
复制主从复制状态OK，进一步查看通过Executed_Gtid_Set查看执行过的GTID：
root@db 15:38: [mysql]> show master status; +-----------+----------+--------------+------------------+---------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +-----------+----------+--------------+------------------+---------------------------------------------+ | on.000002 | 3200431 | | | 763c7ef3-5977-11e8-ae7a-000c2936b80f:1-8730 | +-----------+----------+--------------+------------------+---------------------------------------------+ 1 row in set (0.00 sec) root@db 15:38: [mysql]>
在MySQL5.7版本之后，gtid_executed这个值持久化了，在MySQL库下新增了一张表gtid_executed
root@db 15:38: [mysql]> desc gtid_executed; +----------------+------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------------+------------+------+-----+---------+-------+ | source_uuid | char(36) | NO | PRI | NULL | | | interval_start | bigint(20) | NO | PRI | NULL | | | interval_end | bigint(20) | NO | | NULL | | +----------------+------------+------+-----+---------+-------+ 3 rows in set (0.00 sec) root@db 15:40: [mysql]> root@db 15:41: [mysql]> select * from gtid_executed; +--------------------------------------+----------------+--------------+ | source_uuid | interval_start | interval_end | +--------------------------------------+----------------+--------------+ | 763c7ef3-5977-11e8-ae7a-000c2936b80f | 1 | 6 | +--------------------------------------+----------------+--------------+ 1 row in set (0.00 sec) root@db 15:42: [mysql]>
该表会记录执行的GTID集合信息，因为有了该表，就不用再像MySQL 5.6版本时，必须开启log_slave_updates参数，从库才可以进行赋值。GTID信息会保存在gtid_executed表中，可以关闭从库的binlog，节约binlog的记录开销。在执行reset master时，会清空表内所有的数据。而MySQL 5.7还有一个参数gtid_executed_compresssion_period参数，用来控制gtid_executed表的压缩，该参数默认值为1000，意思是表压缩在执行完1000个事务之后开始。
root@db 15:47: [mysql]> show variables like '%gtid_executed%'; +----------------------------------+-------+ | Variable_name | Value | +----------------------------------+-------+ | gtid_executed_compression_period | 1000 | +----------------------------------+-------+ 1 row in set (0.00 sec) root@db 15:47: [mysql]>
从MySQL5.7.6开始，gid_mode支持动态修改，gtid_mode可取值为：
OFF-------不支持GTID事务
OFF_PERMISSIVE----新的事务是匿名的，同时允许复制的事务可以是GTID，也可以是匿名的
ON_PERMISSIVE---- 新的事务使用GTID,同时允许复制的事务可以是GTID，也可以是匿名的
ON------支持GITD的事务
在线上环境中，有可能把传统复制改为GTID的复制模式的需求，这里特意强调一点，gtid_mode虽然支持动态修改，但不支持跳跃式修改。从ON_PERMISSIVE直接修改为OFF是不可以的，我们可以通过实验来展示传统复制与GTID复制之间的切换过程。见（《MySQL主从复制之传统复制与GTID模式之间切换》）
另外在从库上可以执行show slave status命令来获取接收的gtid(retrieve_gtid_set)和执行的gtid（execute_gtid_set）
[root@localhost mysql]# mysql -uroot -hlocalhost -proot@123 -e "use mysql;show slave status\G;"|grep "Gtid_Set"
Retrieved_Gtid_Set: 763c7ef3-5977-11e8-ae7a-000c2936b80f:1393-10758
Executed_Gtid_Set: 763c7ef3-5977-11e8-ae7a-000c2936b80f:1-10758
[root@localhost mysql]#
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参数的语法
