本文阐述了MySQL中通过GTID、mysqldump备份和PerconaXtrabackup搭建从库的三种方法，包括操作步骤和适用场景。
一、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)
-------+三，基于mysqldump搭建gtid从库，master未停止写入部署
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 --max-allowed-packet=512M >/tmp/alldb.sql
--导出的文件中已经包含了GTID_PURGED的信息，说明备份文件是执行了gtid的位置。
# 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)
重点说明：如果master一直还在写入，这里MASTER_AUTO_POSITION就不能写1，就要写GTID_PURGED这个执行过的开始，上面GLOBAL.GTID_PURGED='78336cdc-8cfb-11e6-ba9f-000c29328504:1-38'，那么master一直有更新操作，这个时候MASTER_AUTO_POSITION就要写执行过的gtid的下一个位置，那就是39，由于master如果uuid是唯一的，MASTER_AUTO_POSITION = 39，如果你写1，那就会出现从库提升gtid已经执行过了。
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 |
+------+-----------------------简单的几个步骤：
1.主库备份
# mysqldump -uadmin -p"hechunyang" -S /tmp/mysql_db01.sock -A -R -E --triggers --single-transaction --max-allowed-packet=512M > full.sql
2.备份文件执行的gtid位置
[root@VM-73-254-tencentos ~]# grep GTID_P full.sql
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '560d72ff-b057-11ee-84ba-5254005c1b84:1-5';
3.拷贝文件full.sql到从库
4.主库执行ddl操作，同时主库执行gtid的位置要比备份gtid位置要大
5.备库导入备份文件
mysql> stop slave;
mysql> reset slave all;
mysql> reset master;
mysql> source /root/full.sql
6，配置gtid主从同步，在从库执行，这里MASTER_AUTO_POSITION = 6，这里要解析一下，为什么是6，而不是1，因为备份文件我并没有过滤掉gtid，所以备份文件导入从库，会执行gtid，也就是上面的备份文件查看到2步骤：SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '560d72ff-b057-11ee-84ba-5254005c1b84:1-5'; 说明导入备份文件，gtid就执行到了5这个位置，那么下一步同步主库的gtid位置就应该是6，因此这里要写6，而不是1，因为1，已经从库执行过了，
mysql> CHANGE MASTER TO MASTER_HOST='9.134.73.254',MASTER_USER='repl',MASTER_PASSWORD='sysrepl',MASTER_PORT=3306,MASTER_AUTO_POSITION = 6;
mysql> start slave;
mysql> show slave status\G;
查看结果，发现接收gtid是从6开始，执行了的gtid，可以对比跟主库。
Retrieved_Gtid_Set: 560d72ff-b057-11ee-84ba-5254005c1b84:6-8
Executed_Gtid_Set: 560d72ff-b057-11ee-84ba-5254005c1b84:1-8
7.测试一下。是否主从同步
主库执行
查看从库
结果可以正常同步
1653
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
