基于mysqldump搭建gtid主从

在实现mysql主从架构的过程中,可以使用基于mysqldump方式来构建主从。mysqldump在备份的过程中已经产生了GTID的相关信息,即这些GTID可以跳过,对于未跳过的GTID则有IO线程复制到从服务器,由SQL线程进行执行。本文主要演示mysqldump在GTID模式下搭建mysql主从。

有关知识点参考: 配置MySQL GTID 主从复制 基于mysqldump快速搭建从库 使用mysqldump导出数据库

一、GTID添加从库的方法

1.如果master所有的binlog还在,安装slave后,直接change master 到master
原理是直接获取master所有的gtid并执行
优点是简单
缺点是如果binlog太多,数据完全同步需要的时间较长,并且需要master一开始就启用了GTID
总结:适用于master也是新建不久的情况

2.通过master或者其它slave的mysqldump备份搭建新的slave.
原理:备份时获取master的数据和这些数据对应的GTID,在Slave端跳过备份包含的GTID
优点是可以避免第一种方法中的不足
缺点操作相对复杂
总结:适用于拥有较大数据集的情况

3、percona xtrabackup
基于xtrabackup备份文件xtrabackup_binlog_info包含了GTID信息
做从库恢复后,需要手工设置:
set@@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';
恢复后,执行change master to
缺点操作相对复杂
总结:适用于拥有较大数据集的情况

二、演示从库搭建

1、演示环境
mysql> system cat /etc/redhat-release
CentOS release 6.7 (Final)
mysql> show variables like 'version';
+---------------+------------+
| Variable_name | Value      |
+---------------+------------+
| version       | 5.7.12-log |
+---------------+------------+

主服务器:192.168.1.245:3306  server_id : 245
从服务器:192.168.1.247:3306  server_id : 247

--在主库端创建复制用户
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%' IDENTIFIED BY '123456'; 

2、直接使用change master(针对本文第一部分,第1小点情形)

此处省略基于gtid配置的参数描述,具体可以参考:配置MySQL GTID 主从复制
在从服务器端直接change master,如下:

SLAVE> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 247   |
+---------------+-------+

Slave> CHANGE MASTER TO  
    -> MASTER_HOST='192.168.1.245',    
    -> MASTER_USER='repl',    
    -> MASTER_PASSWORD='123456',    
    -> MASTER_PORT=3306,    
    -> MASTER_AUTO_POSITION = 1;
Query OK, 0 rows affected, 2 warnings (0.12 sec)

Slave> start slave;
Query OK, 0 rows affected (0.01 sec)

Slave> start slave;
Query OK, 0 rows affected (0.01 sec)

Slave> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.245
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: node3-binlog.000001
          Read_Master_Log_Pos: 457
               Relay_Log_File: node5-relay-bin.000002
                Relay_Log_Pos: 676
        Relay_Master_Log_File: node3-binlog.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              ...............

--主服务器端操作如下
Master> create database tempdb;
Query OK, 1 row affected (0.02 sec)

Master> use tempdb
Database changed
Master> create table t1(id int,ename varchar(20));
Query OK, 0 rows affected (0.09 sec)

Master> insert into t1 values(1,'leshami');
Query OK, 1 row affected (0.08 sec)

--从服务器端验证
Slave> select * from tempdb.t1;
+------+---------+
| id   | ename   |
+------+---------+
|    1 | leshami |
+------+---------+
1 row in set (0.01 sec)

3、基于mysqldump搭建gtid从库 
--准备环境,从库端执行
Slave> stop slave;          --停止重库
Query OK, 0 rows affected (0.01 sec)

Slave> reset slave all;     --重置主从配置信息
Query OK, 0 rows affected (0.02 sec)   

--准备环境,主库端执行  
Master> source sakila-db/sakila-schema.sql  --导入mysql自带的sakila数据库
Master> source sakila-db/sakila-data.sql    --填充数据   

--使用mysqldump导出数据库  
# mysqldump --all-databases --single-transaction --triggers --routines --events \
> --host=localhost --port=3306 --user=root --password=MyP@ssw0rd >/tmp/alldb.sql        

--导出的文件中已经包含了GTID_PURGED的信息
# grep GTID_PURGED /tmp/alldb.sql   
SET @@GLOBAL.GTID_PURGED='78336cdc-8cfb-11e6-ba9f-000c29328504:1-38';

--将备份文件copy到从服务器
# scp /tmp/alldb.sql 192.168.1.247:/tmp

-- 执行reset master,重置从服务器上的binlog
Slave> reset master;
Query OK, 0 rows affected (0.03 sec)

Slave> source /tmp/alldb.sql

Slave> show databases;    --此时tempdb已产生
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sakila             |
| sys                |
| tempdb             |
+--------------------+

--执行change master
Slave> CHANGE MASTER TO  
    -> MASTER_HOST='192.168.1.245',    
    -> MASTER_USER='repl',    
    -> MASTER_PASSWORD='123456',    
    -> MASTER_PORT=3306,    
    -> MASTER_AUTO_POSITION = 1;
Query OK, 0 rows affected, 2 warnings (0.06 sec)

Slave> start slave;
Query OK, 0 rows affected (0.00 sec)

Slave> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.245
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: node3-binlog.000001
          Read_Master_Log_Pos: 25637
               Relay_Log_File: node5-relay-bin.000002
                Relay_Log_Pos: 423
        Relay_Master_Log_File: node3-binlog.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

--主库端执行一些事务
Master> alter table tempdb.t1 modify ename varchar(50);
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0

Master> insert into tempdb.t1 values(2,'http://blog.csdn.net/leshami');
Query OK, 1 row affected (0.02 sec)

--从库端验证结果
Slave> desc tempdb.t1;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(11)     | YES  |     | NULL    |       |
| ename | varchar(50) | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Slave> select * from tempdb.t1;
+------+------------------------------+
| id   | ename                        |
+------+------------------------------+
|    1 | leshami                      |
|    2 | http://blog.csdn.net/leshami |
+------+------------------------------+

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏cmazxiaoma的架构师之路

MySQL主从复制

MySQL复制功能提供分担读负载。 基于二进制日志的复制是异步的,那么复制有什么好处? 1.实现在不同服务器上的数据分布,利用二进制日志增量进行,不需要太多...

1532
来自专栏酷玩时刻

MySql 5.7.18 数据库主从(Master/Slave)同步安装与配置详解

MySql复制的优点: 1.如果主服务器出现问题,可以快速切换到从服务器提供的服务 2.可以在从服务器上执行查询操作,降低主服务器的访问压力 3.可以在从...

863
来自专栏Java架构解析

MySQL主从同步报error 1236

【一】前言:作为MySQL的数据库管理员经常会碰到主从同步的问题,比较常见的有error 1236的报错。刚好最近又碰到了这个报错,以下是整理的文档;

1380
来自专栏从零开始的linux

mysql主从简单配置

环境 hostnameip端口master128.0.0.1013306slave128.0.0.1023306 安装mysql [root@master ~]...

3578
来自专栏散尽浮华

mysql主从同步(4)-Slave延迟状态监控

之前部署了mysql主从同步环境(Mysql主从同步(1)-主从/主主环境部署梳理),针对主从同步过程中slave延迟状态的监控梳理如下: 在mysql日常维护...

3437
来自专栏性能与架构

Mysql 主从复制日志参数优化

MySQL的复制(Replication),实际上就是通过将Master端的Binlog利用IO线程通过网络复制到Slave端,然后再通过SQL线程解析Binl...

3584
来自专栏cmazxiaoma的架构师之路

MySQL基于GTID主从复制的杂谈

先来回顾一下MySQL的二进制知识点。基于Row格式的日志可以避免MySQL主从复制中出现的主从不一致问题。在一个sql语句修改了1000条数据的情况下,基于段...

1485
来自专栏数据和云

例证MySQL GTID与MariaDB GTID的不同之处

GTID是全称是Global Transaction Identifier,可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识...

1072
来自专栏杨建荣的学习笔记

MySQL级联复制的同步问题(一) (r9笔记第71天)

今天碰到一个有些奇怪的问题,有一套环境,在主从复制的时候有一些问题。 大体的流程设计如下: 三个节点位于三个不同的区域,因为节点1和节点3之间的网络存在问题,...

3164
来自专栏程序员同行者

mysql主从同步问题解决汇总

1252

扫码关注云+社区