基于mysqldump搭建GTID主从

在实现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 | | +------+------------------------------+ 

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/acecdd57cc22b46554448032c6a6a7c0.html