MYSQL 多源复制，过滤复制与应用场景

Mysql的使用中，会伴随着一个其他数据库中很少被提到的问题，数据融合。ORACLE ,SQL SERVER ,PG 你可以去分区表，MYSQL 中遇到这样的问题大多去分库分表去解决，虽然现在有了TIDB 可以进行MYSQL 的后续的数据融合，但如果数据量不大的情况下，或者有些 MYSQL 8的新支持的语法需求等等，多源复制还是一个好的选择。

缺点也是显而易见的，多源复制复制不会解决你复制中可能由于你不注意产生的复制的冲突问题。例如重名的数据库，部署系统数据的冲突。下面就来看看如何来多源复制，和其中的一些 “坑”。

首先目前大部分单位的MYSQL 基本上已经启用了 GTID ，这里下面的复制中，全部使用 GTID 的方式进行连接.

测试的机器有

主

192.168.192.200

192.168.192.202

从

192.168.192.201

首先备份 200 和 202 上的数据库，备份的时候，仅仅只备份了需要进行数据同步的数据库，并未进行全部备份，而做多源复制中，也需要这样做，否则做第一个复制还好，后面的复制就不好做了，会有一些问题。

备份是通过mydumper 进行的备份，而mydumper 目前最新的0.95 是TIDB 的团队在维护，应该是靠谱的在mysql 5.7及以下版本（如有不对请指正）

在 200 的机器上

在202 的机器上

在201 的机器上恢复相关的数据库

恢复数据库

同理恢复第二个数据库到winner 数据库

恢复后的数据库 201 是这样的。

下面我们来建立与两台MYSQL 主的复制

CHANGE MASTER TO MASTER_HOST='192.168.198.200', MASTER_USER='admin', MASTER_PORT=3306, MASTER_PASSWORD='XXXX', MASTER_AUTO_POSITION = 1 FOR CHANNEL 'C200';

CHANGE MASTER TO MASTER_HOST='192.168.198.202', MASTER_USER='admin', MASTER_PORT=3306, MASTER_PASSWORD='XXXX', MASTER_AUTO_POSITION = 1 FOR CHANNEL 'C202';

通过上面两个语句，201 就已经与 200， 201 两台机器建立的复制的关系。

启动复制 start slave; 查看201 上的复制状态

我们可以看到对于两台主机的复制是OK 的。而坑其实就不远了

1 举例，为了管理mysql 方便，我们在每台MYSQL 上建立管理库monitor

那么马上问题就在数据汇聚库 201 上出现问题，我先后在 200 ，和 202 两台机器上建立monitor 数据库，按照逻辑来说，201 的复制 关于202 的复制应该会停，但由于特殊的设置，并未停止复制。但201 的错误日志，会毫不留情的记录这个错误。

下面的错误日志报告 202 主机创建数据库的命令失败了

其实这就是配置中，让复制中的DDL 语句的错误忽略产生的结果，但如果我们继续操作一些非DDL 的操作，则复制就不会继续工作了。

我们创建一个表，test1 分表在 200 和 202 机器上，然后插入数据，201 的复制报错了。原因是主键重复。

通过这个事例想说明的问题

1 如果多源复制，建议还是DDL 的错误在多源复制的机器上更宽容一些。

2 不建议有类似比如每个数据库都有的数据库并在这个数据库里面还有同样的表和主键设置

那如果有类似的问题怎么办，必须要在每个MYSQL的物理服务器上有相同命名的数据库，而这个库可以不进行复制。

那就祭出我们的复制过滤来解决问题，原理就是我们对传递过来的日志进行过滤，凡是不在我们允许的复制的数据库list 中的都不进行复制。

我们先停止201 上的复制，stop slave; 然后将201 上的monitor 数据库删除

在201上执行 下图的语句

启动复制，然后我们在原来的 200 和 202 上在对monitor 数据库中的表进行操作，

202 上的表

200 上的表

而 201 上的可以删除 monitor 数据库，复制将过滤一概不是 employees winner 数据库之外的数据。

下图，201 已经没有monitor 数据库

并且201上的复制是正常工作的

MYSQL 的多源复制，其实是一个比较好的功能，也是针对某些分库操作后的数据再次融合和简单的数据联合查询而使用到的功能，当然其中的坑也很多，使用中不注意就会有各种复制的问题。