开发者社区> 余二五> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

使用innobackup实现 基于GTID的从库搭建

简介:
+关注继续查看

对于较大的数据库,我们一般都是使用innobackup进行备份,备份的及恢复的速度更快。


试验环境:

  CentOS6.8 x86_64

  MySQL5.6.34 社区rpm版

  xtrabackup版本:percona-xtrabackup-24-2.4.5-1.el6.x86_64.rpm

  主库:node0 192.168.2.10 (需要安装xtrabackup和lz4)

  从库:node1 192.168.2.11(需要安装xtrabackup和lz4)


5.6下GTID复制必须配的参数(主库和从库都要加上这3行参数):

  gtid-mode=ON

  enforce_gtid_consistency = ON

  log_slave_updates=ON



step1、在从库创建备份文件的存放目录:

mkdir /tmp/db_restore


step2、在主库执行备份(最好开个screen操作,防止网络中断的问题),直接导出到从库机器上:

## 注意这里我们还需要提前在2台机器上安装lz4压缩工具,因为我们的脚本会调用lz4压缩和解压备份文件

innobackupex --user=root \

--password=123456  \

--parallel=4 \

--socket=/tmp/mysql.sock \

--no-timestamp \

--stream=xbstream . |\

lz4 -B4 |\

ssh node1 \

"cat - | lz4 -d -B7 | xbstream -x -C /tmp/db_restore"



step3、在从库node1上看下 主库的gtid位置

cd /tmp/db_restore

cat  xtrabackup_binlog_info 内容如下:

mysql.000008       1949     013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72


为了便于理解,我们去主库查看下对应时间段的binlog,截图如下:

wKiom1kJtfuSNDejAADMrDq3FGI097.png

补充:xtrabackup_binlog_info内容解读:

mysql.000008 表示主库的binlog文件名,1949是尚未执行的binlog position(就是说我们使用传统change master模式的时候MASTER_LOG_FILE='master2-bin.001',MASTER_LOG_POS=1949)。

013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72 指的是已经执行完的GTID编号(就是说我们change master的时候需要先执行set global gtid_purged='013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72';   来purge掉这些GTID)。


step4、在从库上将上一步获取到的这些gtid purge掉,因为这些实际上已经执行过了。

set global gtid_purged='013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72';    

如果提示 ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. 则需要执行下reset master;


step5、配置并启动复制:

CHANGE MASTER TO MASTER_HOST='192.168.2.10', 

 MASTER_USER='rpl', 

 MASTER_PASSWORD='rpl', 

 MASTER_PORT=3306, 

 MASTER_AUTO_POSITION=1;

 

start slave;

show slave status\G


然后可以在主库的test库下尝试创建几个表,验证下复制是否正常。



待确认的问题:

对于某些版本的innobackup,备份出的xtrabackup_binlog_info 里面只有mysql.000008  1949 ,而不带GTID编号。那么我们执行purge的时候就要根据binlog pos 1949这个位置到主库的binlog去找到它上一个的gtid编号(例如上图的就是013bfb27-2edd-11e7-89c7-000c296a2c0d:72)。或者使用传统模式的复制,不用GTID复制即可。










本文转自 lirulei90 51CTO博客,原文链接:http://blog.51cto.com/lee90/1921079,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
基于mysqldump搭建gtid主从
在实现mysql主从架构的过程中,可以使用基于mysqldump方式来构建主从。mysqldump在备份的过程中已经产生了GTID的相关信息,即这些GTID可以跳过,对于未跳过的GTID则有IO线程复制到从服务器,由SQL线程进行执行。
1070 0
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
MySQL 5.7 基于 GTID 主从复制 + 并行复制 + 半同步复制
0 0
简单记GTID从库同步失败一例
环境:Percona MySQL-5.6.24,Fabric 背景:由于测试环境有人手动在库上面执行alter语句出错,导致从库同步中断,然后设置空事务的时候操作失误,跳过了不该跳的地方,结果主从数据发生了不一致的情况。
773 0
使用innobackupex基于从库搭建mysql主从架构
MySQL的主从搭建大家有很多种方式,传统的mysqldump方式是很多人的选择之一。但对于较大的数据库则该方式并非理想的选择。
828 0
基于GTID搭建主从MySQL
想让主从之间使用gtid的方式同步数据,需要我们在配置文件中开启mysql对gtid相关的配置信息 找到my.cnf ,在mysqld模块中加入如下的配置。(主库从库都这样)
0 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载