基于mysqldump搭建GTID主从

387次阅读

共计 4631 个字符，预计需要花费 12 分钟才能阅读完成。

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

一、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://www.linuxidc.com      |
+------+------------------------------+