django-\/\/ i K | 
  ## 实验环境


此次实验的环境如下

- MySQL 5.7.25

- Redhat 6.10

- 操作系统账号:mysql

- 数据库复制账号:repl

- 复制格式:基于行的复制


| IP地址 |主从关系|复制账号  |复制格式  |
| --- | --- | --- | --- |
| 11.12.14.29 | 主库 | repl |Row-Based  |
| 11.12.14.30| 从库(半同步)| repl |Row-Based|


这节我们的内容为MySQL的复制，MySQL复制有两种形式

- 基于二进制日志文件位置
- 基于GTID

前面几节我们重点讲了GTID相关的内容

如果一步步看下来的话应该已经有了一定的认识

对于这节的内容应该会很容易理解

下面我们来说下如何一步步搭建基于GTID的MySQL复制





## 1. 开启GTID功能

虽然从库可以不需要开启二进制日志功能，这里我们推荐主从库同时开启二进制日志功能，方便主从切换

主从库开启GTID功能需要如下参数

如果未开启则需要在my.cnf文件中加入如下参数，设置重启数据库生效

**主库**

```
[mysqld] 
server-id = 11121429
binlog_format = row
log_bin = /datalog/mysql/binlog/mysql-bin.log
expire_logs_days = 14
gtid_mode=ON 
enforce-gtid-consistency=true
log-slave-updates=ON
```

**从库**

```
[mysqld] 
server-id = 11121430
binlog_format = row
log_bin = /datalog/mysql/binlog/mysql-bin.log
expire_logs_days = 14
read_only=1
gtid_mode=ON 
enforce-gtid-consistency=true
log-slave-updates=ON
```

我们需要保证server-id不一样，这里我们用IP地址命名

从库使用了read_only参数确保无其他写入

之后重启数据库

这里需要注意的是如果从库是由主库克隆而来，这时的uuid是一样的，这样也会报错

## 2. 查看UUID是否一致

需要注意的是如果从库是由主库克隆而来，这时的uuid是一样的，这样也会报错

该文件位于daadir的auto.cnf文件中

```
vim /data/mysql/data/auto.cnf
```
如果一样可删除该文件后重新启动数据库即可，这时会生成一个新的文件

## 3. 建立复制账号

接下来我们建立一个独立的用于复制的账号

**主库和从库**

```
mysql> CREATE USER 'repl'@'11.12.14.29' IDENTIFIED BY 'rpl'; 
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'11.12.14.29';
mysql> CREATE USER 'repl'@'11.12.14.30' IDENTIFIED BY 'rpl'; 
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'11.12.14.30';
mysql>flush privileges;
```

这里我们限制该账号只能从同步的两台服务器上连接


## 4. 备份主库

我们通过mysqldump备份主库的文件

这里我们分两种情况来进行备份


### 4.1 全新主库

如果我们用来搭建复制的主库是全新的，变更的数据变化量不大，而且所有二进制文件都存在，即gtid_purged为空的话，我们使用如下命令进行备份

**主库**

```
mysqldump -S /data/mysql/data/mysql.sock -usystem -p  --single-transaction  --all-databases --master-data=2  --set-gtid-purged=off   --triggers --events --routines --hex-blob > /tmp/dumpmaster.sql
```

### 4.2 运行一段时间的主库

如果我们用来搭建复制的主库已经运行一段时间了，变更的数据量很大，而且二进制文件有被清理过，即gtid_purged不为空的话，我们使用如下命令备份

```
mysqldump -S /data/mysql/data/mysql.sock -usystem -p   --single-transaction --all-databases --master-data=2  --set-gtid-purged=auto  --triggers --events --routines --hex-blob > /tmp/dumpmaster.sql
```

细心的读者可能看出来了我们这次使用的是--set-gtid-purged=auto 参数，代表如果开启了GTID，则输出set gtid_purged语句

具体原因在Part 7说过

这样备份文件为有set gtid_purged语句

需要注意的是:mysqldump里面gtid_purged信息并非主库的gtid_purged参数的内容，而是gtid_executed的内容


## 5. 文件传输

接下来将主库的dump文件传到备份，之后更改备库的文件权限

**主库**

```
scp /tmp/dumpmaster.sql root@11.12.14.30:/tmp

```

**从库**

```
chown mysql:mysql /tmp/dumpmaster.sql
```
    
## 6. 备库导入数据

接下来我们将备份的数据导入到备份

这里同样我们对用上面备份的内容，有两种导入方式

### 6.1 全新主库

```
shell> mysql -S /data/mysql/data/mysql.sock -usystem -p </tmp/dumpmaster.sql
```

### 6.2 运行一段时间的主库

```
mysql> reset master;
shell> mysql -S /data/mysql/data/mysql.sock -usystem -p </tmp/dumpmaster.sql
```

这里我们需要先使用reset master 来重置日志，同时也将gtid_executed清空，这样才能执行set gtid_purged语句，这时gtid_purged的内容为主库所有执行过的GTID



## 7.开始同步

接下来我们开启同步

这里的话无论那种备份和导入方式都使用如下命令开启同步

从库会自动同步主库的日志

- 第一种情况为同步主库所有日志
- 第二种情况为同步除gtid_purged外的所有日志




之后使用如下命令开启同步    

```
mysql> change master to master_host='11.12.14.29', master_user='repl', master_password='rpl',master_auto_position = 1;


mysql > start slave;
```

## 8. 查看同步状态

使用如下命令查看同步是否正常

```
mysql>show slave status\G
```


[image:665 size:orig]


[image:666 size:orig]




主要关注如下几点

-  Slave_IO_Running需要为YES
-  Slave_SQL_Running需要为YES
-  Seconds_Behind_Master需要为0
-  Auto-Position需要为1


## 9. 重启和重置复制

使用如下命令关闭重启
```
mysql>stop slave;
mysql>start slave;
```

我们可以独立的重启IO进程或者SQL进程

```
mysql>stop slave sql_thread;
mysql>stop slave io_thread;

mysql>start slave io_thread;
mysql>start slave sql_thread;
```

使用如下命令重置复制

```
mysql>reset slave all;
```


该命令更多内容后面介绍



## 10. 参考资料

本专题内容翻译自官方文档并结合自己的环境

[https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-howto.html](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-howto.html)