MySQL基于GTID主从搭建

目录
  • 一、用xtarbackup备份数据库
    • 1.1 优势
    • 1.2 安装
    • 1.3 使用
      • 1.3.1 普通备份
      • 1.3.2 tar备份
      • 1.3.3 xbstream备份
      • 1.3.4 恢复
  • 二、基于GTID做数据同步
    • 2.1 GTID的概念
    • 2.2 GTID的组成
    • 2.3 GTID的原理
    • 2.4 GTID的优势
    • 2.5 具体搭建过程
    • 2.5.1 开启主(master)Gtid
      • 2.5.2 在master上进行数据备份
      • 2.5.3 解压备份的数据
      • 2.5.4 配置slave的配置文件
      • 2.5.5 恢复数据
      • 2.5.6 获取GTID节点
      • 2.5.7 配置主从
    • 2.6 已运行经典复制mysql服务器转向GTID复制

前言:

用xtarbackup来同步数据,然后基于GTID来设置主从。

一、用xtarbackup备份数据库

1.1 优势

使用xtarbackup来做主从的前期准备是因为xtarbackup备份数据和恢复数据都很快,特别适合数据量很大的数据库备份,而且它的安装非常的简单,使用也很简单....(巴拉巴拉,废话编不出来了)。

1.2 安装

具体版本根据自己的具体情况来选择。就下面这几步就安装好了,是不是非常简单.....

# rpm -Uvh https://www.percona.com/redir/downloads/percona-release/redhat/percona-release-0.1-3.noarch.rpm
# yum list | grep percona
# yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL
# rpm -Uvh ftp://rpmfind.net/linux/epel/6/x86_64/libev-4.03-3.el6.x86_64.rpm
# yum install percona-xtrabackup –y

1.3 使用

1.3.1 普通备份

innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 /data/backupMysql/

1.3.2 tar备份

(1)、备份到本地

# 不压缩
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=tar /data/backupMysql/>/data/mysql.tar

# 压缩
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=tar /data/backupMysql/ | gzip >/data/mysql.tar.gz

(2)、备份到远程

# 不压缩
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=tar /data/backupMysql/ | ssh root@192.168.1.7 \ "cat - >/data/mysql.tar

# 压缩
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=tar /data/backupMysql/ | | ssh root@192.168.1.7 \ "gzip >/data/mysql.tar.gz

(3)、解压方式

# 未经过压缩的文件解压
tar xvf mysql.tar -C /data

# 压缩过的文件解压
tar zxvf mysql.tar.gz -C /data

1.3.3 xbstream备份

(1)、备份到本地

# 不压缩
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=xbstream /data/backupMysql/>/data/mysql.xbstream

# 压缩
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=xbstream --compress /data/backupMysql/ >/data/mysql_compress.xbstream

(2)、备份要远程

# 不压缩
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=xbstream /data/backupMysql/| ssh root@192.168.1.7 "xbstream -x -C /backup/stream"

# 压缩
innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=xbstream --compress /data/backupMysql/ | ssh root@192.168.1.7 "xbstream -x -C /backup/stream"

(3)、解压方式

#### 未压缩的
xbstream -x < mysql.xbstream -C /data

#### 压缩过的
# 1、先解压xbstream
xbstream -x < mysql_compress.xbstream -C /data
# 2、再解压qp压缩格式
for bf in `find . -iname "*\.qp"`; do qpress -d $bf $(dirname $bf) && rm $bf; done

注:如果xtrabackup版本大于2.1.4,可以直接通过以下方式解压第二步。
innobackupex --decompress /data

1.3.4 恢复

先将原备份压缩包解压到一个目录,然后执行下面语句恢复。

innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --copy-back /var/lib/mysql/backup/

注:在做备份,解压,恢复的过程中可以借助分屏工具,我喜欢用screen。

二、基于GTID做数据同步

2.1 GTID的概念

  • 1、全局事务标识:global transaction identifiers。
  • 2、GTID是一个事务一一对应,并且全局唯一ID。
  • 3、一个GTID在一个服务器上只执行一次,避免重复执行导致数据混乱或者主从不一致。
  • 4、GTID用来代替传统复制方法,不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
  • 5、MySQL-5.6.5开始支持的,MySQL-5.6.10后开始完善。
  • 6、在传统的slave端,binlog是不用开启的,但是在GTID中slave端的binlog是必须开启的,目的是记录执行过的GTID(强制)。

2.2 GTID的组成

GTID = source_id:transaction_id source_id:用于鉴别原服务器,即mysql服务器唯一的的server_uuid,由于GTID会传递到slave,所以也可以理解为源ID。 transaction_id:为当前服务器上已提交事务的一个序列号,通常从1开始自增长的序列,一个数值对应一个事务。         示例:           3E11FA47-71CA-11E1-9E33-C80AA9429562:23 前面的一串为服务器的server_uuid,即3E11FA47-71CA-11E1-9E33-C80AA9429562,后面的23为transaction_id

2.3 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、在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描。

2.4 GTID的优势

  • 1、更简单的实现failover,不用以前那样在需要找log_file和log_pos。
  • 2、更简单的搭建主从复制。
  • 3、比传统的复制更加安全。
  • 4、GTID是连续的没有空洞的,保证数据的一致性,零丢失。

2.5 具体搭建过程

对于GTID的配置,主要修改配置文件中与GTID特性相关的几个重要参数,mysql版本建议mysql-5.6.5版本以上。

2.5.1 开启主(master)Gtid

其主要配置如下:

[mysqld]
#GTID:
server_id=135                #服务器id
gtid_mode=on                 #开启gtid模式
enforce_gtid_consistency=on  #强制gtid一致性,开启后对于特定create table不被支持

#binlog
log_bin=master-binlog
log-slave-updates=1
binlog_format=row            #强烈建议,其他格式可能造成数据不一致

#relay log
skip_slave_start=1

2.5.2 在master上进行数据备份

innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --stream=tar /data/backupMysql/ | | ssh root@192.168.1.7 \ "gzip >/data/mysql.tar.gz

2.5.3 解压备份的数据

tar zxvf /data/mysql.tar.gz -C /data/baskup

2.5.4 配置slave的配置文件

[mysqld]
#GTID:
gtid_mode=on
enforce_gtid_consistency=on
server_id=143

#binlog
log-bin=slave-binlog
log-slave-updates=1
binlog_format=row      #强烈建议,其他格式可能造成数据不一致

#relay log
skip_slave_start=1

2.5.5 恢复数据

innobackupex --defaults-file=/etc/my.cnf --user=root --password=123456 --copy-back /data/backup

2.5.6 获取GTID节点

more /data/backup/2018-02-08_15-03-18/xtrabackup_binlog_info

2.5.7 配置主从

(1)、在master上授权

grant replication slave on *.* to slaveuser@'192.168.1.7'  identified by "c2xhdmV1c2Vy";

(2)、在slave上配置

stop slave;
SET GLOBAL gtid_purged="c5b5ffe7-ce66-11e7-9a19-00163e00013d:1-515758";
CHANGE MASTER TO MASTER_HOST='192.168.1.6',MASTER_PORT=3306,MASTER_USER='slaveuser',MASTER_PASSWORD='c2xhdmV1c2Vy',MASTER_AUTO_POSITION=1;
start slave;

2.6 已运行经典复制mysql服务器转向GTID复制

  • a、按本文2.5.2描述配置参数文件;
  • b、所有服务器设置global.read_only参数,等待主从服务器同步完毕;  mysql> SET @@global.read_only = ON;
  • c、依次重启主从服务器;
  • d、使用change master 更新主从配置;mysql> CHANGE MASTER TO > MASTER_HOST = host,  > MASTER_PORT = port, > MASTER_USER = user,   > MASTER_PASSWORD = password,   > MASTER_AUTO_POSITION = 1;
  • e、从库开启复制  mysql> START SLAVE; f、验证主从复制

到此这篇关于MySQL基于GTID主从搭建的文章就介绍到这了,更多相关MySQL主从搭建内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • MySQL GTID主备不一致的修复方案

    目录 方案一:重建 Replicas 前提条件 优点 缺点 操作步骤 Master Slave 方案二:使用percona-toolkit进行数据修复 前提条件 优点 缺点 操作步骤 背景示例 校验一致性 方案一:重建 Replicas MySQL 5.6及以上版在复制中引入了新的全局事务ID(GTID)支持. 在启用了GTID模式的情况下执行MySQL和MySQL 5.7的备份时,Percona XtraBackup会自动将GTID值存储在xtrabackup_binlog_info中. 该信

  • MYSQL数据库GTID实现主从复制实现(超级方便)

    一.添加Maria源 vi /etc/yum.repos.d/MariaDB.repo 粘贴阿里云的最新mariadb镜像: [mariadb] name = MariaDB baseurl = https://mirrors.aliyun.com/mariadb/yum/10.5/centos7-amd64/ gpgkey=https://mirrors.aliyun.com/mariadb/yum/RPM-GPG-KEY-MariaDB gpgcheck=1 安装新版本的MariaDB yu

  • MySQL5.7不停业务将传统复制变更为GTID复制的实例

    由于GTID的优势,我们需要将传统基于file-pos的复制更改为基于GTID的复制,如何在线变更成为我们关心的一个点,如下为具体的方法: 目前我们有一个传统复制下的M-S结构: port 3301 master port 3302 slave master上(3301): [zejin] 3301>select * from t_users; +----+------+ | id | name | +----+------+ | 1 | hao | | 2 | zhou | +----+---

  • 详解MySQL主从复制实战 - 基于GTID的复制

     基于GTID的复制 简介 基于GTID的复制是MySQL 5.6后新增的复制方式. GTID (global transaction identifier) 即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID. 在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致. 而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可

  • MySQL5.6 GTID模式下同步复制报错不能跳过的解决方法

    数据库版本: mysql> select version(); +------------+ | version() | +------------+ | 5.6.10-log | +------------+ 1 row in set (0.02 sec) 同步复制信息: mysql> show slave status\G; *************************** 1. row *************************** Slave_IO_State: Wait

  • MySQL在线开启或禁用GTID模式

    目录 基本概述 在线开启GTID 1. 设置GTID校验ENFORCE_GTID_CONSISTENCY为WARN 2. 设置GTID校验ENFORCE_GTID_CONSISTENCY为ON 3. 设置GTID_MODE为OFF_PERMISSIVE 4. 设置GTID_MODE为ON_PERMISSIVE 5. (关键点)确保匿名事务回放完毕 6. 触发一轮日志切换FLUSH LOGS 7. 正式开启GTID_MODE为ON 8. 修改配置文件确保GTID参数持久化 9. 修改复制模式为GT

  • MySQL主从复制之GTID模式详细介绍 

    目录 一.GTID概述 二.GTID相较与传统复制的优势 三.GTID自身存在哪些限制 四.GTID工作原理简单介绍 五.如何开启GTID复制 六.查看GTID相关参数 七.GTID与传统模式建立复制时候语句的不同点 八.GTID同步状态简单解析 一.GTID概述 MySQL5.6 在原有主从复制的基础上增加了一个新的复制方式,即基于GTID的复制方式,它由UUID和事务ID两个部分组成,具有如下特点. GTID事务是全局唯一性的,并且一个事务对应一个GTID值. 一个GTID值在同一个MySQ

  • Mysql GTID Mha配置方法

    Gtid + Mha +Binlog server配置: 1:测试环境 OS:CentOS 6.5 Mysql:5.6.28 Mha:0.56 192.168.1.21 mysql1 M1 192.168.1.22 mysql2 S1 192.168.1.23 mysql3 S2 Mha manage.Binlog server 2:配置/etc/my.cnf相关参数,在3各节点中分别配置 binlog-format=ROW log-slave-updates=true gtid-mode=on

  • MySQL GTID全面总结

    01 GTID简介 GTID,全称Global transaction identifiers,也称之为全局事务ID.MySQL-5.6.2开始支持,MySQL-5.6.10后完善,GTID 分成两部分,一部分是服务的UUid,UUID保存在mysql数据目录的auto.cnf文件中, 这是一个非常重要的文件,不能删除,这一部分是不会变的.下面是一个uuid的值举例: [root@dev01 mysql]# cat auto.cnf  [auto] server-uuid=ac1ebad0-ef

  • MySQL基于GTID主从搭建

    目录 一.用xtarbackup备份数据库 1.1 优势 1.2 安装 1.3 使用 1.3.1 普通备份 1.3.2 tar备份 1.3.3 xbstream备份 1.3.4 恢复 二.基于GTID做数据同步 2.1 GTID的概念 2.2 GTID的组成 2.3 GTID的原理 2.4 GTID的优势 2.5 具体搭建过程 2.5.1 开启主(master)Gtid 2.5.2 在master上进行数据备份 2.5.3 解压备份的数据 2.5.4 配置slave的配置文件 2.5.5 恢复数

  • MySQL主从搭建(多主一从)的实现思路与步骤

    背景: 由于最近公司项目好像有点受不住并发压力了,优化迫在眉睫.由于当前系统是单数据库系统原因,能优化的地方也尽力优化了但是数据库瓶颈还是严重限制了项目的并发能力.所以就考虑了添加数据库来增大项目并发能力. 思路: 1: 创建集中库: 主要就是存储历史数据.作为查询使用. 2:创建多个业务库:满足项目高并发的能力. demo环境: 1: VM ware 虚拟机 - centOS 7 centOS-1: 192.168.194.3 主 100-------业务库 centOS-2: 192.168

  • MySQL示例DTID主从原理解析

    目录 1.GTID基本概念 2.GTID优点 3.GTID的工作原理 4.GTID比传统复制的优势 5.启动的方法 6.GTID(一主一从)配置 6.1环境: 6.2在主库上给从库授权: 6.3确保数据一致操作 6.4配置主库 6.5配置从库 6.6配置主从复制 7.GTID(一主俩从) 8.GTID(俩主一从) 1.最新环境 2.所有服务器均关闭防火墙或者放行防火墙 3.授权连接 master01库授权普通用户 slave进行连接 master02授权普通用户 slave进行连接 4.分别进行

  • MySQL基于SSL协议进行主从复制的详细操作教程

    当mysql跨越互联网进行复制时别人可以窃取到mysql的复制信息,这些信息是明文的,因此存在不安全性,这里通过ssl对复制的信息进行加密.当在客户没有固定ip而要访问服务器时,mysql要允许任意地址的访问,服务端和客户端通过证书验证可以防止暴力破解. 开始之前让我们先来回顾一下SSL协议客户端OpenSSL的安装过程: 安装openssl mkdir /test/setup cd /test/setup tar zxvf openssl-0.9.8b.tar.gz cd openssl-0.

  • Centos7实现MySQL基于日志还原数据的示例代码

    简介 Binlog日志,即二进制日志文件,用于记录用户对数据库操作的SQL语句信息,当发生数据误删除的时候我们可以通过binlog日志来还原已经删除的数据,还原数据的方法分为传统二进制文件还原数据和基于GTID的二进制文件还原数据 前期准备 准备一台Centos7虚拟机,关闭防火墙和selinux,配置IP地址,同步系统时间,安装MySQL数据库 传统二进制日志还原数据 修改配置文件 [root@localhost ~]# vi /etc/my.cnf server-id=1 log-bin=b

  • 详解Spring与Mybatis的整合方法(基于Eclipse的搭建)

    项目工程总览: 项目路径建的包不是唯一,只要之后配置的路径映射正确即可 Emp.java <properties> <spring.version>5.1.5.RELEASE</spring.version> <mybatis.version>3.4.6</mybatis.version> <log4j.version>1.2.17</log4j.version> </properties> <depen

  • IntelliJ IDEA基于SpringBoot如何搭建SSM开发环境的步骤详解

    之前给大家在博文中讲过如何通过eclipse快速搭建SSM开发环境,但相对而言还是有些麻烦的,今天玄武老师给大家介绍下如何使用IntelliJ IDEA基于SpringBoot来更快速地搭建SSM开发环境,相比于传统搭建方式,极少的配置文件和配置信息会让你彻底爱上它. 环境搭建步骤详解 第1步:创建Spring Initializr项目 在IntelliJ IDEA中新建项目,选择Spring Initializr,JDK版本选择自己安装的版本(首次使用可能显示没有,那么就点击New去按照步骤创

  • MySQL 基于时间点的快速恢复方案

    之所以有这样一篇文章,是因为在前几天的一个晚上,要下班的时候,业务方忽然有一个需求,是需要恢复一个表里面的数据,当时问了下情况,大概是这样的:业务方不小心在一个表里面做了一个update的操作,可能是where条件没有写对,导致表里面的数据被写坏了,但是数据目前还没有落盘,只是在内存中的值修改了,现在要求恢复到之前的数据.万幸,这份数据是平台上某些商品的价格,基本上是有限个商品,然后价格值也都是固定的,之前有对这个价格表进行备份,于是给他直接重新导入了一份价格表的数据,这个问题也算是解决了. 当

  • mysql5.6主从搭建以及不同步问题详解

    目录 一.mysql主从复制原理 二.mysql编译安装 三.主从配置 四.主从不同步 系统:centos6.6 主:192.168.142.129 mysql-5.6.30.tar.gz 从:192.168.142.130 192.168.142.131 mysql-5.6.30.tar.gz 一.mysql主从复制原理 (1) master将改变记录到二进制日志(binary log)中: (2) slave将master的binary log events拷贝到它的中继日志(relay l

随机推荐