使用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.0000034328013bfb27-2edd-11e7-89c7-000c296a2c0d:1-10

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

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

如果提示 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库下尝试创建几个表,验证下复制是否正常。

时间: 2024-10-14 02:08:34

使用innobackup实现 基于GTID的从库搭建的相关文章

【基础】 mysqldump 创建基于GTID的从库

对于小型的数据库,我们可以直接使用mysqldump全库导出导入来创建从库. 试验环境: CentOS6.8 x86_64 MySQL5.6.34 社区rpm版 主库:node0 192.168.2.10 从库:node1 192.168.2.11 5.6下GTID复制必须配的参数(主库和从库都要加上这3行参数): gtid-mode=ON enforce_gtid_consistency = ON log_slave_updates=ON step1.在主库导出并scp传输到node1: my

mysqldump 创建基于GTID的从库

对于小型的数据库,我们可以直接使用mysqldump全库导出导入来创建从库. 试验环境:  CentOS6.8 x86_64  MySQL5.6.34 社区rpm版  主库:node0 192.168.2.10 从库:node1 192.168.2.11 5.6下GTID复制必须配的参数(主库和从库都要加上这3行参数):  gtid-mode=ON  enforce_gtid_consistency = ON  log_slave_updates=ON step1.在主库导出并scp传输到nod

mysql5.7.26 基于GTID的主从复制环境搭建

简单工作原理: (1)从库执行 change master to 语句,会立即将主库信息记录到master.info中 (2)从库执行 start slave语句,会立即生成IO_T和SQL_T (3)IO_T 读取master.info文件,获取到主库信息 (4)IO_T 连接主库,主库会立即分配一个DUMP_T,进行交互 (5)IO_T 根据master.info binlog信息,向DUMP_T请求最新的binlog (6)主库DUMP_T,经过查询,如果发现有新的,截取并反回给从库IO_

mysql5.6基于GTID模式之高可用架构搭建-MHA(mha0.56)

一.测试环境部署: mysql1:192.168.110.131   作为master mysql2:192.168.110.132   作为slave mysql3:192.168.110.130   作为slave,同时作为MHA的管理机 虚拟IP:192.168.110.100 二.mysql主从环境搭建和MHA安装 1.mysql主从搭建自行搭建(基于GTID复制,打开log_bin,复制规则默认,复制所有库表),这里不再说明. 2.安装MHA节点软件:rpm -ivh mha4mysq

MYSQL 基于GTID的复制

1.概述 从MYSQL5.6 开始,mysql开始支持GTID复制. 基于日志点复制的缺点: 从那个二进制日志的偏移量进行增量同步,如果指定错误会造成遗漏或者重复,导致数据不一致. 基于GTID复制: 1.从服务器会告诉主服务器已执行的事务的GTID值. 2.主库会告诉从哪些GTID事务没有被执行. 同一个事务在指定的从库执行一次. 什么是GTID GTID即全局事务ID,器保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID. GTID=source_id:transaction_i

MySQL主从复制--MySQL5.6基于GTID及多线程复制

大纲 一.系统环境 二.MySQL初始化安装过程 三.基于GTID的主从模式配置过程 一.系统环境 系统环境 CentOS5.8 x86_64 master.network.com    master    172.16.1.101 slave.network.com     slave     172.16.1.105 软件包 mysql-5.6.26-linux-glibc2.5-x86_64.tar.gz(二进制通用安装包) 拓扑图 二.MySQL初始化安装过程 1.时间同步 [[emai

基于GTID的主从复制数据库

基于GTID的主从复制数据库 全局身份识别 GTID(global transaction identifier) 为了实现主备数据库的强一致性 GTID = source_id:transaction_id source_id 表示执行事务的主库 transaction_id 是一个序列号,表示这个主库上执行的第 n 个事务. server_uuid是系统自动生成的,用来的替代server_id,因为source_id是手工设置的,可能会有冲突 数据库的安装和初始化 server33,44:

企业级-Mysql双主互备高可用负载均衡架构(基于GTID主从复制模式)

前言: 原理与思想 这里选用GTID主从复制模式Mysql主从复制模式,是为了更加确保主从复制的正确性.健康性与易配性.这里做的是两服务器A,B各有Mysql实例3310,两个实例间互为主从 主从复制模式采用GTID主从复制模式,在服务器A,B上配置keepalived负载均衡,通过VIP连接数据库,目的是一旦有某数据库宕机,keepalived 就会立即建VIP执行另外一台 健康的数据库实例上,实现快速切换,避免单点故障,从而保证业务的正常运行. 这里只做了 双主+keepalived  ,

myslq-5.6基于GTID的主从复制实现

mysql - 5.6 :GTID 机制 slave-parallel-workes=启动的线程个数等于小于数据库的库数       0表示禁用       在mysql-5.6中使用基于GTID的复制功能 一.简单主从模式配置步骤 1.配置主从节点的服务配置文件 1.1.配置master节点:[mysqld]binlog-format=ROWlog-bin=master-binlog-slave-updates=truegtid-mode=on enforce-gtid-consistency