其他分享
首页 > 其他分享> > GTID主从 与 传统主从复制

GTID主从 与 传统主从复制

作者:互联网

 

一、主从复制 

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

标签:binlog,主从复制,slave,log,master,MASTER,主从,GTID
来源: https://www.cnblogs.com/dreammer/p/15766073.html