一、主从复制 

1.）普通主从复制：

　　普通主从复制主要是基于二进制日志文件位置的复制，因此主必须启动二进制日志记录并建立唯一的服务器ID，复制组中的每个服务器都必须配置唯一的服务器ID。如果您省略server-id（或者明确地将其设置为其默认值0），则主设备将拒绝来自从设备的任何连接。 
2.） GTID 主从：　

（1.）基本概念

　　MySQL 5.6 的新特性之一，全局事务标识符（GTID）是创建的唯一标识符，并与在源（主）服务器上提交的每个事务相关联。此标识符不但是唯一的，而且在给定复制设置中的所有服务器上都是唯一的。所有交易和所有GTID之间都有一对一的映射关系 。它由服务器ID以及事务ID组合而成。这个全局事务ID不仅仅在原始服务器上唯一，在所有存在主从关系 的mysql服务器上也是唯一的。正是因为这样一个特性使得mysql的主从复制变得更加简单，以及数据库一致性更可靠。一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。

　　一个GTID被表示为一对坐标，用冒号（:）分隔，如下所示：GTID = source_id:transaction_id，source_id标识的源服务器。通常情况下，服务器 server_uuid用于这个目的。这transaction_id是一个序列号，由在此服务器上提交事务的顺序决定 .

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

 

　　在传统的主从复制slave端，binlog是不用开启的，但是在GTID中slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）。GTID用来代替classic的复制方法，不在使用binlog+pos开启复制。而是使用master_auto_postion=1的方式自动匹配GTID断点进行复制。

　　mysql的主从复制是十分经典的一个应用，但是主从之间总会有数据一致性（data consistency ）的问题，一般情况从库会落后主库几个小时，而且在传统一主多从(mysql5.6之前)的模型中当master down掉后，我们不只是需要将一个slave提成master就可以，还要将其他slave的同步目的地从以前的master改成现在master，而且bin-log的序号和偏移量也要去查看，这是十分不方便和耗时的，但mysql5.6引入gtid之后解决了这个问题。

红色代表GTID，绿色代表传统主从：

 

（2.）GTID的工作原理：

1、当一个事务在主库端执行并提交时，产生GTID，一同记录到binlog日志中。
2、binlog传输到slave,并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID。
4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
5、如果没有记录，slave就会执行该GTID事务，并记录该GTID到自身的binlog，
   在读取执行事务前会先检查其他session持有该GTID，确保不被重复执行。
6、在解析过程中会判断是否有主键，如果有就用二级索引，如果没有就用全部扫描。

 

 

二、GTID参数配置

1、主master：

[mysqld]
#GTID:
server_id=1 #服务器id
gtid_mode=on #开启gtid模式
log_slave_updates ## 表示即可以当从也可以当主
enforce_gtid_consistency=on #强制gtid一致性，开启后对于特定create table不被支持

#binlog
log_bin=master-binlog
#log-bin=/data/mysql/mysql-bin.log    //binlog日志文件,(文件名如果是绝对路径,必须指定索引文件)
#log_bin_index =    /var/lib/mysql/mysql-bin.index     //是binlog文件的索引文件，这个文件管理了所有的binlog文件的目录
log-slave-updates=1 
binlog_format=row #binlog日志格式，强烈建议，其他格式可能造成数据不一致
expire_logs_days=7            //binlog过期清理时间

#relay logskip_slave_start=1

 

 

2、从slave：

与主的配置没有区别，仅仅只是server_id不一致。

 

三、配置主从

1.）master:

创建并授权salve远程访问的用户：

GRANT REPLICATION SLAVE ON *.* TO root@192.168.50.28 IDENTIFIED BY '123456';
flush privileges;

 

查看授权slave用户表：

show grants for user@localhost;

 

查看binlog信息：show master status;

 

2.）GTID—slave;（注意：GTID主从必须启用MASTER_AUTO_POSITION而且不能跟bin与pos同时配置。）

CHANGE MASTER TO MASTER_HOST='192.168.50.116',MASTER_PORT=3306,MASTER_USER='root',MASTER_PASSWORD='123456',MASTER_AUTO_POSITION=1;
start slave;
show slave status\G;

#MASTER_AUTO_POSITION： （mysql5.6.5及其后续版本）进行change master to时使用MASTER_AUTO_POSITION = 1，slave连接master将使用基于 
GTID的复制协议。等于0则恢复到老的文件复制协议。

 

 3.）传统复制—slave配置;（这里的bin与pos根据实际情况更换）

CHANGE MASTER TO MASTER_HOST='192.168.50.116',MASTER_PORT=3306,MASTER_USER='root',MASTER_PASSWORD='123456', master_log_file='mysql-bin.000003',master_log_pos=308;

start slave;
show slave status\G; 

 

关键：在配置文件中启用GTID的情况下，change语句才是决定启用GTID还是传统主从的关键。

进行主备切换的时候，一般都会先对主库进行只读操作(on)，然后主备同步完成后，再把备库置为可读写(off)。这样可以避免切换的过程中双写引起脏数据。：set global read_only=on/off

 

 

 四、特殊情况下，需要重置主从

stop slave;

reset slave all;  #重置全部的从信息

reset master;  #重置主

 

 

五、事物跳过（传统与GTID的跳过方法不同）

1.传统

set global sql_slave_skip_counter = 1;

#可以忽略N个事件（event），通常一个SQL是一个事件。

 

2.GTID跳过事务冲突

首先，我们需要先查看当前SLAVE复制的进度：SHOW SLAVE STATUS\G

Retrieved_Gtid_Set:aaa-bbb-ccc-ddd:N   （表示收到的事务）
Executed_Gtid_Set:aaa-bbb-ccc-ddd:N    （表示已经执行完的事务）

看Executed_Gtid_Set 到了31这个事务GTID位置，在这下一个位置（32）上发生错误。这时候，我们需要手工调整SLAVE已清除的GTID列表 GTID_PURGED，人为通知SLAVE哪些事务已经被清除了，后续可以忽略：

 STOP SLAVE;
 RESET MASTER;
 SET @@GLOBAL.GTID_PURGED = “3a16ef7a-75f5-11e4-8960-deadeb54b599:1-283,f2b6c829-9c87-11e4-84e8-deadeb54b599:1-32”;
 START SLAVE;

上面这些命令的用意是，忽略 f2b6c829-9c87-11e4-84e8-deadeb54b599:32 这个GTID事务，下一次事务接着从 33 这个GTID开始，即可跳过上述错误。

从服务器上负责同步的有二类线程: 1) IO thread       2) SQL thread

Slave_IO_Running:从服务器正从主服务器上读取BINLOG日志,并写入从服务器的中继日志.
Slave_SQL_Running:进程正在读取从服务器的BINLOG中继日志，并转化为SQL执行

IO thread 决定了Retrieved_Gtid_Set
SQL thread 决定了Executed_Gtid_Set

IO thread负责获取master上的binary log, 然后多个sql threads负责执行。由于IO thread先于SQL thread，Retrieved_Gtid_Set可能会略多于Executed_Gtid_Set。比如： SHOW slave STATUS \G

.......
.......
Retrieved_Gtid_Set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-9
Executed_Gtid_Set: 67cd9435-7cae-11e2-aa8d-00241db92e69:1-7 
Auto_Position: 1

 

1.）注入空事务：

stop  slave;

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';    #要想跳过错误的GTID或则是想要跳过的GTID，就需要指定下一个事物的执行版本

BEGIN; COMMIT;　　　　#注入一个空事务

SET GTID_NEXT='AUTOMATIC';　　#自动寻找GTID事务

一旦所有事务标识符以这种方式使用空事务恢复后，您必须刷新并清除从属服务器的二进制日志，如下所示，其中 N是当前二进制日志文件名称 的非零后缀；或者reset  slave;
FLUSH LOGS;
PURGE BINARY LOGS TO 'master-bin.00000N';

start  slave;

 

2.）重置master方法跳过错误

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> SET @@GLOBAL.GTID_PURGED ='8f9e146f-0a18-11e7-810a-0050568833c8:1-4'
mysql> START SLAVE;

注意：在GTID主从的建立初期，slave的数据一定要是从master mysqldump过去的并且更加--all-databases参数。否则手动补齐的数据会出现slave_sql_running为NO的情况，这是因为主的操作记录会保存在GTID与binlog中，然后slave会同步主的GTID与binlog并进行相应的操作，这时两边的数据虽然是一致的，但是同步过来master的GTID中包含了主做过的一些sql操作，而此时slave的环境不满足sql语句的执行就会冲突。解决办法是：1.）不断的执行跳过事务的操作直到没有报错。2.）刷新master的GTID“reset master”然后重新再slave执行change同步。

 

六、报错案例：

1.）

2017-10-12T09:59:27.660287Z 4 [ERROR] Slave I/O for channel '': Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work. Error_code: 1593
解决方法：
如果是copy的data目录可能会出现这个错，将data目录里auto.cnf 文件中的uuid改为与master不一样的即可。

2.）传统主从

2017-10-12T10:09:15.365312Z 4 [ERROR] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file', Error_code: 1236
解决办法：
是因为找不到master的二进制文件，查看master的binlog二进制文件、pos位置是否与slave相同，不相同关闭salve并在slave执行CHANGE MASTER TO MASTER_LOG_FILE='mysqld-bin.000011',MASTER_LOG_POS=106;更改，然后开启start slave;并进行查看show slave status\G

3.） GTID主从

Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

解决办法：忽略purged的部分，强行同步
master确认已经purge的部分：show global variables like '%gtid%';
stop slave，在slave上通过set global gtid_purged='xxxx'的方式，跳过已经purge的部分

4.）

主从不同步，但slave显示双yes，日志无报错问题。

这个解决方法是下下策，我不知道不同步的原因是什么，如果有知道的T友，请评论告知。

重置主从：reset master                reset slave 

备份主的全库到slave：
mysqldump -h 192.168.50.116 -uroot -p123456 --all-databases --skip-lock-tables --set-gtid-purged=off > qk.sql

然后从导入：mysql -uroot -p123456 <aaa.sql 

导入时若提示：ERROR 1840 (HY000) at line 24: @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.则在本地执行reset master即可。导入成功后重新开启slave同步，如若slave需要重新挂载在master端，则执行命令change时忽略MASTER_AUTO_POSITION即可。

注意：

开启主从复制之后，就不可以在从的上面进行操作，否则会出现slave_sql_running为NO的提示。
当已经在从库进行删除或则添加数据时，挽救的方法就是关闭slave，然后将删除的数据创建回来或将添加的数据删除，目的是为了与master一致，然后开启slave。最好是将从库设置为只读模式，但是无法对super的用户起效。

5.）

Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

 解决办法：

这类报错往往是因为master清除了相关的GTID事务导致无法同步的。通常是因为从库因为某些原因需要重新接受master的GTID事务，比如像slave导入备份重新指向master。这时就需要在master执行：show global variables like '%gtid%';  找出被purged的条目，然后再slave执行本文中 “GTID跳过事务冲突”的步骤即可。

优秀文章分享：

http://www.cnblogs.com/luckcs/articles/6295992.html

http://blog.csdn.net/leshami/article/details/50630691