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