如何搭建mysql5.7多源复制

这种架构一般用在以下三类场景

1. 备份多台 Server 的数据到一台如果按照数据切分方向来讲，那就是垂直切分。比如图 2，业务 A、B、C、D 是之前拆分好的业务，现在需要把这些拆分好的业务汇总起来备份，那这种需求也很适用于多源复制架构。实现方法我大概描述下：业务 A、B、C、D 分别位于 4 台 Server，每台 Server 分别有一个数据库来隔离前端的业务数据，那这样，在从库就能把四台业务的数据全部汇总起来，而不需要做额外的 *** 作。那没有多源复制之前，要实现这类需求，只能在汇总机器上搭建多个 MySQL 实例，那这样势必会涉及到跨库关联的问题，不但性能急剧下降，管理多个实例也没有单台来的容易。

2. 用来聚合前端多个 Server 的分片数据。

同样，按照数据切分方向来讲，属于水平切分。比如图 3，按照年份拆分好的数据，要做一个汇总数据展现，那这种架构也非常合适。实现方法稍微复杂些：比如所有 Server 共享同一数据库和表，一般为了开发极端透明，前端配置有分库分表的中间件，比如爱可生的 DBLE。

3. 汇总并合并多个 Server 的数据

第三类和第一种场景类似。不一样的是不仅仅是数据需要汇总到目标端，还得合并这些数据，这就比第一种来的相对复杂些。比如图 4，那这样的需求，是不是也适合多源复制呢？答案是 YES。那具体怎么做呢？

MySQL是一个高速度、高性能、多线程、开放源代码，建立在客户/服务器(Client/Server)结构上的关系型数据库管理系统(RDBMS)。它始于1979年，最初是MichaelWidenius为瑞典TcX公司创建的UNIREG数据库系统，当时的UNIREG没有SQL(StructuredQueryLanguage结构化查询语言)接口，限制了它的应用。

1996年5月，Widenius开发出了MySQL的最初版本，开始在Internet上公开发行。MySQL的开发人员从一开始就一直关注它的性能，为此不惜特性集，直到今天，MySQL依然保持本色，以高速度高性能为首要原则。随着时间的推移，MySQL也加入了大型数据库产品的高级特性，如存储过程、视图、触发器等，使其在企业级数据库系统中开始被部署应用[1]。

2008年10月，SUN公司收购了MySQLAB公司，开始进入开源领域。随着重量级 *** 作系统Solaris的开源，SUNMySQL在数据库市场占有的份额将会进一步提高。因此，在生产环境中部署具有负载均衡功能的MySQL服务器集群，对于提高企业数据库应用系统的速度、稳定性及可伸缩性具有很大的现实意义，也可以有效降低应用系统的投资成本。

一、负载均衡基本思路

在一个服务器集群中，尽可能的平均负载量。通常做法是在服务器前端设置一个负载均衡器（专门的硬件设备），MySQL的负载均衡，通常都离不开数据分片（把数据分割成小块，存储到不同的db节点中）、复制等 *** 作。

负载均衡的主要贡献，除了均发数据库请求，还可提供管理读/写策略。在分发请求时则确定那些节点可写，可读，随即将请求发送到指定节点上执行 *** 作。

二、实现负载均衡的方式：

1、mysql读写分离：

mysql复制时，产生了多个数据副本（备库），为减少服务器压力，备库用于处理读 *** 作，主库可同时处理读写是mysql集群实现读写分离的常用策略。

由于备库的复制是异步的，无法实时同步，读写分离的主要难点也在于备库上的脏数据。通常如果使用备库进行读，一般对数据的实时性要求不能太高。对此，mysql提供了几种常见的读写分离方式，例如基于查询的读写分离、基于脏数据、基于会话等，有兴趣可继续研究。

mysql设置的读写分离，减少了主库的请求量，将大量读的 *** 作发送给备库，实现负载均衡。

2、修改DNS

在高并发负载均衡（一）——企业架构分析和DNS中详细介绍了DNS以及DNS如何实现负载，简言之，通过n个服务器IP指定到一个域名，根据请求的不同标识特征，将请求发送给不同的IP服务器进行处理。

3、引入中间件

mysql官方提供了一个mysql负载的中间件，mysql_proxy，也需要在服务器上进行安装，修改配置文件（mysql的服务器IP）,实质与nginx类似，也是一个代理服务器。

4、利用mysql复制分流查询 *** 作

利用mysql的主从复制可以有效的分流更新 *** 作和查询 *** 作，具体的实现是一个主服务器，承担更新 *** 作，多台从服务器，承担查询 *** 作，主从之间通过复制实现数据的同步。多台从服务器一方面用来确保可用性，一方面可以创建不同的索引满足不同查询的需要。

对于主从之间不需要复制全部表的情况，可以通过在主的服务器上搭建一个虚拟的从服务器，将需要复制到从服务器的表设置成blackhole引擎，然后定义replicate-do-table参数只复制这些表，这样就过滤出需要复制的binlog，减少了传输binlog的带宽。因为搭建的虚拟的从服务器只起到过滤binlog的作用，并没有实际纪录任何数据，所以对主数据库服务器的性能影响也非常的有限。

通过复制分流查询的存在的问题是主数据库上更新频繁或者网络出现问题的时候，主从之间的数据可能存在差异，造成查询结果的异议，应用在设计的时候需要有所考虑。

5、采用分布式数据库架构

mysql从5.0.3开始支持分布式事务，当前分布式事务只对Innodb存储引擎支持。分布式的数据库架构适合大数据量，负载高的情况，有良好的扩展性和高可用性。通过在多台服务器之间分布数据实现在多台服务器之间的负载平均，提高了访问的执行效率。具体实现的时候，可以使用mysql的Cluster功能（NDB引擎）或者自己编写程序来实现全局事务。

现在还不是，性能有点差，之前看到过测试报告， MySQL-python直接连数据库qps可以到3W，通过fabric连的话，大概只有300多一点。 但是sharding的话 有人测出来 用不同的驱动 性能差异比较巨大。 没在实际生产总用过，不过看了看，HA效果应该不错，分片的话，建议针对服务测一下。

---