作者:马文斌
MySQL OCP 认证,PostgresSQL PGCA 认证,擅长 MySQL、PostgreSQL、dble 等开源数据库相关产品的备份恢复、读写分离、SQL 调优、监控运维、高可用架构设计等。目前任职于月亮小屋(中国)有限公司。
本文来源:原创投稿
*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。
一、背景
有 4 个地区工厂的数据,需要同步到 idc。 之前有个方案是用阿里的 otter 管理平台去同步到 idc 机房。 运行一段时间过后,发现 otter 平台会不断的往 idc 发包,建立几百个空连接,这样导致 idc 的网络造成拥堵。
后来经过讨论,还是采用 MySQL 源生自带的主从复制方案,那源生自带的主从复制方案又有两种:一种是 GTID;一种是 pos 位点信息。那为什么要采用 GTID 复制呢?肯定有他的优势。
这里简单列举了几点:
1. 如果是单源复制的情况下,可以很方便的搭建主从;
2. 基于 GTID 的复制可以忽略已经执行过的事务,减少了数据发生不一致的风险;
3. 避免因为设置位点信息不准确而造成主从不一致的情况。
下面开始做多源复制的操作。
导出 4 个工厂的数据到 192.168.100.5,在该服务器上运行:
cd /data/backupmysqldump -uroot -p -h192.168.100.1 mysqldump -uroot -p -h192.168.100.2 mysqldump -uroot -p -h192.168.100.3 mysqldump -uroot -p -h192.168.100.4
这里只先导入 3 个实例的数据,然后开启主从,最后再添加一个,我们看看这样是否方便添加。
4.2 导入三个实例
use db01;source /data/backup/db01.sql;use db03;source /data/backup/db03.sql;use db04;source /data/backup/db04.sql;stop slave ;reset slave all;reset master; show master status \G File: mysql-bin.000001 Position: 155 Binlog_Do_DB: Binlog_Ignore_DB:Executed_Gtid_Set:
4.3 设置 GTID
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '39e42c4d-876f-11ea-8229-286ed488e793:1-31,8a426026-b5e7-11ea-8816-0050568399c4:1-62183,f3d8b026-ba76-11ea-985d-000c29b82d1f:1-36244,39e42c4d-876f-11ea-8229-286ed488e793:1-31,5d7ef438-f249-11ea-a518-0894ef181fcf:1-5980,8a426026-b5e7-11ea-8816-0050568399c4:1-56548';
4.4 设置主从关系
change master to master_host='192.168.100.1',master_user='repl',master_password='123456',master_auto_Position=1 for channel 'ims_guangzhou';change master to master_host='192.168.100.3',master_user='repl',master_password='123456',master_auto_Position=1 for channel 'ims_tianjin';change master to master_host='192.168.100.4',master_user='repl',master_password='123456',master_auto_Position=1 for channel 'ims_kunshan';
start slave;show slave status\G
use db01;create table tb1(id int primary key);
在 100.5 的 db01 的库上是可以查的,说明可以同步。
为什么要尝试添加一个从库,这里主要是测试下,看看添加一个从库,麻不麻烦?如果不麻烦的话,还是可以用 GTID 的模式的。
5.1 找到最后一个库的 GTID
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ 'a97612c1-b947-11ea-bcf9-005056812835:1-19065';
5.2 终止 slave
5.3 加入其他的 GTID
/data/mysqlLog/logsmkdir binlogbakcp mysql-bin.000001 binlogbak/
SET @@GLOBAL.GTID_PURGED= 'a97612c1-b947-11ea-bcf9-005056812835:1-19065,39e42c4d-876f-11ea-8229-286ed488e793:1-31,5d7ef438-f249-11ea-a518-0894ef181fcf:1-6107,8a426026-b5e7-11ea-8816-0050568399c4:1-62290,f3d8b026-ba76-11ea-985d-000c29b82d1f:1-36379'
5.4 添加从库
change master to master_host='192.168.100.2', master_user='repl', master_password='123456', master_auto_Position=1 for channel 'ims_chongqing';
5.5 查看是否同步
use db01;drop table tb1;
use db01;show tables;+| Tables_in_db01 |+| equitment_info || event_code_info || ims_monitor || oee_data || oee_process_re |+
GTID 对于单源复制还是很方便,但是对于多源复制,这里就需要特别注意:
这里就会引入一个问题,如果是级联复制的情况下,reset master 的时候,会把本机的所有 binlog 清理掉。如果下一级的从库存在延迟,没有及时的把 binlog 传过去,就会造成主从中断,这里我们该怎么避免呢?看这里:
技术分享 | Xtrabackup 备份中 Xtrabackup_binlog_info 文件记录的 GTID 信息是否准确?
深度分析 | MGR 相同 GTID 产生不同 transaction 故障分析
点一下“阅读原文”了解更多资讯