一步步搭建基于GTID的MySQL复制

bsbforever

发布于 2020-08-19 16:23:22

7190

发布于 2020-08-19 16:23:22

文章被收录于专栏：时悦的学习笔记

实验环境

此次实验的环境如下

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 --all-databases --master-data=2  --set-gtid-purged=off   --triggers --events --routines > /tmp/dumpmaster.sql

4.2 运行一段时间的主库

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

mysqldump -S /data/mysql/data/mysql.sock -usystem -p --all-databases --master-data=2  --set-gtid-purged=auto  --triggers --events --routines > /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

主要关注如下几点

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;

该命令更多内容后面介绍

10. 参考资料

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

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

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2020-06-04，如有侵权请联系 cloudcommunity@tencent.com 删除

访问管理

云数据库 SQL Server

数据库

sql

本文分享自宅必备微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度