这种架构一般用在以下三类场景
10年积累的成都网站建设、网站设计经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站制作后付款的网站建设流程，更有梅县免费网站建设让你可以放心的选择与我们合作。
1. 备份多台 Server 的数据到一台如果按照数据切分方向来讲，那就是垂直切分。比如图 2，业务 A、B、C、D 是之前拆分好的业务，现在需要把这些拆分好的业务汇总起来备份，那这种需求也很适用于多源复制架构。实现方法我大概描述下：业务 A、B、C、D 分别位于 4 台 Server，每台 Server 分别有一个数据库来隔离前端的业务数据，那这样，在从库就能把四台业务的数据全部汇总起来，而不需要做额外的操作。那没有多源复制之前，要实现这类需求，只能在汇总机器上搭建多个 MySQL 实例，那这样势必会涉及到跨库关联的问题，不但性能急剧下降，管理多个实例也没有单台来的容易。
2. 用来聚合前端多个 Server 的分片数据。
同样，按照数据切分方向来讲，属于水平切分。比如图 3，按照年份拆分好的数据，要做一个汇总数据展现，那这种架构也非常合适。实现方法稍微复杂些：比如所有 Server 共享同一数据库和表，一般为了开发极端透明，前端配置有分库分表的中间件，比如爱可生的 DBLE。
3. 汇总并合并多个 Server 的数据
第三类和第一种场景类似。不一样的是不仅仅是数据需要汇总到目标端，还得合并这些数据，这就比第一种来的相对复杂些。比如图 4，那这样的需求，是不是也适合多源复制呢？答案是 YES。那具体怎么做呢？
先假设有主机 A 和 B ( Linux 系统)，主机 A 的 IP 分别是 1.2.3.4 (当然，也可以是动态的)，主机 B 的 IP 是 5.6.7.8 。两个主机都装上了 PHP+Mysql ，现在操作的是主机 A 上的资料，如果另外一个主机 B 想跟 A 的资料进行同步，应该怎么做呢？
OK，我们现在就动手。
首先，如果要想两个主机间的资料同步，一种方法就是主机 A 往主机 B 送资料，另外一种主法就是主机 B 到主机 A 上拿资料，因为 A 的 IP 是动态的(假设)，所以我们就得从主机 A 往主机 B 送资料。
在主机 B 上创建一个 Mysql 账户。
# GRANT ALL ON test.* TO user@% IDENTIFIED BY "password"; //创建用户 user,可以从任何机器访问到主机 B 上的 test 数据库。
如果这里显示错误，先把 % 改为一个 IP ，然后再利用 phpMyAdmin 把 IP 改为 % ，测试无误后就可以写 php 程序。
?
$link=mysql_pconnect("localhost","user","password");
mysql_pconnect("localhost","user","password"); //连接本机(主机A)的数据库
mysql_select_db("test"); //选择数据库test
$re=mysql_query("select * from table order by id desc");
$num=mysql_numrows($re);
if (!empty($num)) {
$id=mysql_result($re,0,"id"); //获得本机table表的最大ID
}
mysql_close($link); //关闭与本机数据库的连接
$link=mysql_pconnect("5.6.7.8","test","test");
mysql_pconnect("5.6.7.8","test","test"); //连接主机B的数据库
mysql_select_db("test"); //选择数据库test，此数据库应该与主机A上test数据库的结构一样。
$re=mysql_query("select * from table order by id desc");
$num=mysql_numrows($re);
if (!empty($num)) {
$remote_id=mysql_result($re,0,"id"); //获得主机Btable表的最大ID
}
if ($id$remote_id) {
$result_id=$id-$remote_id; //如果主机A中table的最大ID大于主机B中table表的最大ID，说明两个
} 的资料不同
mysql_close($link); //关闭主机B的数据库连接
$link=mysql_pconnect("localhost","user","password");
mysql_pconnect("localhost","user","password");
mysql_select_db("test");
if (empty($result_id)) $result_id=0;
if (empty($remote_id)) $remote_id=0; //如果主机B中的table的最大ID为空(里面没有资料),那么就等0
$re=mysql_query("select * from table limit $remote_id,$result_id"); //取出主机A中table表与主机B中table表里不同的资料
$num=mysql_numrows($re);
if (!empty($num)) {
for ($i=0;$i$num;$i++) {
$test[$i]=mysql_result($re,$i,"test"); //把不同的资料放入一个数组里
}
}
mysql_close($link); //关闭主机A的数据库连接
$link=mysql_pconnect("5.6.7.8","user","password");
mysql_pconnect("5.6.7.8","user","pasword");
mysql_select_db("test");
for ($j=0;$j$i;$j++) { //这里的i等于在比较主机A与主机B上table表不同资料的数量
mysql_query("insert into table (test) values(\'$test[$j]\')");
}
mysql_close($link); //关闭主机B的数据库连接
?
这时就初步实现了 A 主机和 B 主机数据的同步，但现在还需要人手动每次去激活这个程序，有没有办法把它作为一个脚本一样的，放在 crontab 里面指定时间自动执行呢？
在安装 php 时会自动生一个叫 php 的可执行文件，一般在/你安装的 php 目录 /bin 下面，不过较底的版本好像没有，如果没有这个文件，你就得升级你的 php 。
#php -q test.php
php 原本是应用在网页应用的﹐因此它会送出 HTML 的 Header﹐但是在此我们是要将 php 用作 Shell Script﹐"-q" 就是表示不要送出 Header 的意思.
最后编辑 /etc/crontab 里的文件，加上下面这一句。
0 0 * * * root /home/httpd/html/test //每天晚上零点执/home/httpd/html/test文件(具体使用方法请查看cron的相关资料)
OK，到这里差不多就已完成 Mysql 数据的同步了，如果各位还有兴趣的话，可以想一个连编辑、删除都能同步的更好的办法。
如何对MySQL数据库中的数据进行实时同步
实现两个Mysql数据库之间同步同步原理：
MySQL 为了实现replication 必须打开bin-log 项，也是打开二进制的MySQL 日志记录选项。MySQL 的bin log 二
进制日志，可以记录所有影响到数据库表中存储记录内容的sql 操作，如insert / update / delete 操作，而不记录
select 这样的操作。因此，我们可以通过二进制日志把某一时间段内丢失的数据可以恢复到数据库中（如果二进制日
志中记录的日志项，包涵数据库表中所有数据，那么， 就可以恢复本地数据库的全部数据了）。 而这个二进制日志，
如果用作远程数据库恢复，那就是replication 了。这就是使用replication 而不用sync 的原因。这也是为什么要设
置bin-log = 这个选项的原因。
mysql同步数据到hive大部分公司目前都是走的jdbc的方式。
这种方式有两个好处：
也有不好的地方：
这一步最主要的细节是将mysql库的所有binlog数据全部打入一个kafka topic，格式使用json。格式如下：
这一步的主要的细节在于写入到hdfs的结构，以及为什么不直接写入hive。
不写入到hive表的原因在于，binlog的数据结构是不固定的，而hive的结构相对是比较固定的。如果要写入到hive的话，就需要将不同的表的binlog写入到不同的hive表中，这个维护成本太高了。而且spark其实可以直接读取hdfs的json文件，因此直接放hdfs就好了。
写入到hdfs的话，考虑到后续读这个数据是要按照表去读增量数据，所以写入的目录一定是要带日期和表名称的。我这边用的目录结构是这样的：
也就是说要在flink根据数据所属的db、table_name、和日期将数据写入到不同的目录里。
在这一步的处理的过程中遇到了一些比较重要的参数问题。
2.如上所述checkpoint的时间间隔。不仅仅会影响checkpoint的频率，而且会影响hdfs文件的大小，而hdfs文件的大小可能会对hdfs的性能有很大影响。这个值如果太大，就会造成数据延迟太高，如果太小就会造成小文件过多。我这边设置的是5分钟。
细心的看官，这个时候会问了，既然你的目录是分table的，那么每个table每5分钟的binlog数据量是不一样的。对于某些大的mysql表，我们可能每5分钟生成一个文件还能接受。对于一些比较小的表，每五分钟生成一个文件那么文件就会非常小。所以我这边又做了一层的筛选，我把mysql的大的表筛选出来，只同步大的表到hdfs，用以binlog的数据同步。因为本身binlog的方式同步mysql数据为的就是节约mysql的读取压力，而小的表对于不会有太大压力，这些表可以直接通过jdbc的方式去同步。
这个是整个环节里面最复杂的一部分，涉及的细节也比较多。
首先，我们要明确一下总体的思路是什么。总体的思路就是要读取hdfs上的老的历史数据，然后和新的binlog数据合并生成新的快照。
其实这中间还涉及到一些其他的细节，比如mysql表结构变更，或者mysql和hive的数据结构不一致的情况。
另外我们这边还存在多个db的相同的表导入到hive的一张表中的其他问题，我就不赘述了。
