mysql5.7多源复制

在mysql5.7.9版本GA之前我们就已经开始使用他的多源复制功能，来实现数据分析部门的需求，将多个系统的数据汇聚到一台服务器上。GA之后用的更加大胆些了。现在贴出来分享下。

需求由数据分析部门提出，DB部来实现，在今年九月份的时候，开始投入使用，关于这种放法，这一过程中踩过的坑，容我一点点道来。

第一阶段：实时同步5个业务库（位于不同服务器）数据至一台服务器。所有线上的复制均使用GTID的形式。建立复制关系是个相对简单的过程，

1>通过mysqldump分别导出五个库的全量数据，当时数据量大概在100G左右。dump语法如下：

./mysqldump -S /data/msyql/mysql3306.sock -p –single-transaction –set-gtid-purged=OFF –master-data=2 -B test>/data/test.sql

其实在开始使用的阶段上，没有使用–master-data=2这个参数，但后来发现，如果不加这个参数是有问题的，会出现丢数据的现象，至于为什么会丢数据，另外再写吧。通过以上dump文件，将会得到一个包含复制起始点的，完整的历史备份，也许这样说更加通俗易懂一点，包含复制起始点，越来越佩服自己说话的能力了，复制起始点，其实就是一个set-gtid-purged值，这个值得意思是，事务已经执行到了哪个GTID,但是在dump文件里，这个值是被注释掉的。

2>通过mysql客户端逐个恢复5个备份文件，当然最好在这一过程中不要写binlog进入新的服务器。

mysql -h -u -p -P
(最好在screen中执行，不然ssh客户端断了，有点日狗)

3> 建立复制关系

在建立复制关系之前，要向新的服务器写入gtid-purged参数，来告诉服务器，下一步同步binlog数据时，哪些是执行过的，就不需要再复制过来了。

set global gtid-purged=’[b]*********[/b],[b]******[/b],[b]********[/b],[b]******[/b],[b]***********[/b]’;大概是这样的格式，此值由之前5台服务器的备份文件中获得。逗号隔开就行。

5.7建立多源复制跟5.6基本相同，sql如下：

change master to master_host = ‘10.127.37.20’,master_port=3306,master_user=’repl’,master_password=’[b]****[/b]’,master_auto_position=1 for channel ‘**‘;

其实跟5.6普通的复制建立，只不过是多了一个for channel option，来唯一标识复制链路。这样的语句要执行5次。

然后就是开启复制，

start slave；

show slave status\G 检查复制状态

大概过程就是这样。当然，新的服务器的配置文件，可以仔细斟酌一番，你可以忽略库里不想要的表，binlog的参数等等。

第二阶段: 业务在不断扩张，新的业务上线，需要将他们的数据接入离线分析系统，就需要添加复制链路，这一过程如下所示：

第三阶段:错误修复，由于是离线分析库，可能会做一些与线上不同的mysql库操作，当然，可以在一开始就将其忽略掉，避免不必要的麻烦。具体遇到的不同的错误，可以以后慢慢补充。

第四阶段：诡异现象处理，丢失的索引，当然这里说的丢失的索引，不是另外一篇博客里写的由于limit问题，见这里，/article/3596914.html导致的索引使用不上的情况，而是真正的丢失了。当遇到诡异的情况发生时，先不要想着bug什么的，可能是忽略了某个细节问题。事情是因为下面的这个工具引起的：

pt-online-schema-change，好像又要说好多东西才能解释清楚，先添加个链接吧，慢慢说。

第五阶段：数据量开始暴涨，从开始汇聚100G到1个T，再到两个T。这个库开始变得很重，对，是很重，让人觉得很重，不得已开始去寻找新的出路，路在前方。