MySQL Replication 经常使用架构

前言

MySQLReplicaion自己是一个比较简单的架构，就是一台MySQL服务器（Slave）从另外一台MySQL服务器（Master）进行 日志的复制而后再解析日志并应用到自身。一个复制环境仅仅只须要两台运行有MySQLServer的主机便可，甚至更为简单的时候咱们能够在同一台物理服 务器主机上面启动两个mysqldinstance，一个做为Master而另外一个做为Slave来完成复制环境的搭建。可是在实际应用环境中，咱们能够 根据实际的业务需求利用MySQLReplication的功能本身定制搭建出其余多种更利于ScaleOut的复制架构。如DualMaster架构， 级联复制架构等。下面咱们针对比较典型的三种复制架构进行一些相应的分析介绍。 

mysql  复制理解 http://www.cnblogs.com/hustcat/archive/2009/12/19/1627525.html

常规复制架构　 Master - Slaves

在实际应用场景中，MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端 廉价扩展解决方案。由于只要Master和Slave的压力不是太大（尤为是Slave端压力）的话，异步复制的延时通常都不多不多。尤为是自从 Slave端的复制方式改为两个线程处理以后，更是减少了Slave端的延时问题。而带来的效益是，对于数据实时性要求不是特别Critical的应用， 只须要经过廉价的pcserver来扩展Slave的数量，将读压力分散到多台Slave的机器上面，便可经过分散单台数据库服务器的读压力来解决数据库 端的读性能瓶颈，毕竟在大多数数据库应用系统中的读压力仍是要比写压力大不少。这在很大程度上解决了目前不少中小型网站的数据库压力瓶颈问题，甚至有些大 型网站也在使用相似方案解决数据库瓶颈。

这个架构能够经过下图比较清晰的展现：

一个Master复制多个Slave的架构实施很是简单，多个Slave和单个Slave的实施并无实质性的区别。在Master端并不Care 有多少个Slave连上了本身，只要有Slave的IO线程经过了链接认证，向他请求指定位置以后的BinaryLog信息，他就会按照该IO线程的要 求，读取本身的BinaryLog信息，返回给Slave的IO线程。

你们应该都比较清楚，从一个Master节点能够复制出多个Slave节点，可能有人会想，那一个Slave节点是否能够从多个Master节点上面进行复制呢？至少在目前来看，MySQL是作不到的，之后是否会支持就不清楚了。

MySQL不支持一个Slave节点从多个Master节点来进行复制的架构，主要是为了不冲突的问题，防止多个数据源之间的数据出现冲突，而造 成最后数据的不一致性。不过据说已经有人开发了相关的patch，让MySQL支持一个Slave节点从多个Master结点做为数据源来进行复制，这也 正是MySQL开源的性质所带来的好处。

对于Replication的配置细节，在MySQL的官方文档上面已经说的很是清楚了，甚至介绍了多种实现Slave的配置方式，在下一节中咱们也会经过一个具体的示例来演示搭建一个Replication环境的详细过程以及注意事项。

 

dualMaster复制架构 Master - Master 

有些时候，简单的从一个MySQL复制到另一个MySQL的基本Replication架构，可能还会须要在一些特定的场景下进行Master的 切换。如在Master端须要进行一些特别的维护操做的时候，可能须要停MySQL的服务。这时候，为了尽量减小应用系统写服务的停机时间，最佳的作法 就是将咱们的Slave节点切换成Master来提供写入的服务。

可是这样一来，咱们原来Master节点的数据就会和实际的数据不一致了。当原Master启动能够正常提供服务的时候，因为数据的不一致，咱们就 不得不经过反转原Master-Slave关系，从新搭建Replication环境，并以原Master做为Slave来对外提供读的服务。从新搭建 Replication环境会给咱们带来不少额外的工做量，若是没有合适的备份，可能还会让Replication的搭建过程很是麻烦。

为了解决这个问题，咱们能够经过搭建DualMaster环境来避免不少的问题。何谓DualMaster环境？实际上就是两个 MySQLServer互相将对方做为本身的Master，本身做为对方的Slave来进行复制。这样，任何一方所作的变动，都会经过复制应用到另一方 的数据库中。

可能有些读者朋友会有一个担忧，这样搭建复制环境以后，难道不会形成两台MySQL之间的循环复制么？实际上MySQL本身早就想到了这一点，因此 在MySQL的BinaryLog中记录了当前MySQL的server-id，并且这个参数也是咱们搭建MySQLReplication的时候必须明 确指定，并且Master和Slave的server-id参数值比须要不一致才能使MySQLReplication搭建成功。一旦有了server- id的值以后，MySQL就很容易判断某个变动是从哪个MySQLServer最初产生的，因此就很容易避免出现循环复制的状况。并且，若是咱们不打开 记录Slave的BinaryLog的选项（--log-slave-update）的时候，MySQL根本就不会记录复制过程当中的变动到 BinaryLog中，就更不用担忧可能会出现循环复制的情形了。

下如将更清晰的展现DualMaster复制架构组成：

经过DualMaster复制架构，咱们不只可以避免由于正常的常规维护操做须要的停机所带来的从新搭建Replication环境的操做，由于我 们任何一端都记录了本身当前复制到对方的什么位置了，当系统起来以后，就会自动开始从以前的位置从新开始复制，而不须要人为去进行任何干预，大大节省了维 护成本。

不只仅如此，DualMaster复制架构和一些第三方的HA管理软件结合，还能够在咱们当前正在使用的Master出现异常没法提供服务以后，很是迅速的自动切换另一端来提供相应的服务，减小异常状况下带来的停机时间，而且彻底不须要人工干预。

固然，咱们搭建成一个DualMaster环境，并非为了让两端都提供写的服务。在正常状况下，咱们都只会将其中一端开启写服务，另一端仅仅只 是提供读服务，或者彻底不提供任何服务，仅仅只是做为一个备用的机器存在。为何咱们通常都只开启其中的一端来提供写服务呢？主要仍是为了不数据的冲 突，防止形成数据的不一致性。由于即便在两边执行的修改有前后顺序，但因为Replication是异步的实现机制，一样会致使即便晚作的修改也可能会被 早作的修改所覆盖，就像以下情形：

时间点MySQL A MySQL B

1 更新x表y记录为10

2 更新x表y记录为20

3获取到A日志并应用，更新x表的y记录为10（不符合指望）

4获取B日志更新x表y记录为20（符合指望）

这中情形下，不只在B库上面的数据不是用户所指望的结果，A和B两边的数据也出现了不一致。

固然，咱们也能够经过特殊的约定，让某些表的写操做所有在一端，而另一些表的写操做所有在另一端，保证两端不会操做相同的表，这样就能避免上面问题的发生了。

 

级联复制架构 Master –Slaves - Slaves

在有些应用场景中，可能读写压力差异比较大，读压力特别的大，一个Master可能须要上10台甚至更多的Slave才可以支撑注读的压力。这时 候，Master就会比较吃力了，由于仅仅连上来的SlaveIO线程就比较多了，这样写的压力稍微大一点的时候，Master端由于复制就会消耗较多的 资源，很容易形成复制的延时。

遇到这种状况如何解决呢？这时候咱们就能够利用MySQL能够在Slave端记录复制所产生变动的BinaryLog信息的功能，也就是打开— log-slave-update选项。而后，经过二级（或者是更多级别）复制来减小Master端由于复制所带来的压力。也就是说，咱们首先经过少数几 台MySQL从Master来进行复制，这几台机器咱们姑且称之为第一级Slave集群，而后其余的Slave再从第一级Slave集群来进行复制。从第 一级Slave进行复制的Slave，我称之为第二级Slave集群。若是有须要，咱们能够继续往下增长更多层次的复制。这样，咱们很容易就控制了每一台 MySQL上面所附属Slave的数量。这种架构我称之为Master-Slaves-Slaves架构

这种多层级联复制的架构，很容易就解决了Master端由于附属Slave太多而成为瓶颈的风险。下图展现了多层级联复制的Replication架构。

固然，若是条件容许，我更倾向于建议你们经过拆分红多个Replication集群来解决

上述瓶颈问题。毕竟Slave并无减小写的量，全部Slave实际上仍然仍是应用了全部的数据变动操做，没有减小任何写IO。相反，Slave越多，整个集群的写IO总量也就会越多，咱们没有很是明显的感受，仅仅只是由于分散到了多台机器上面，因此不是很容易表现出来。

此外，增长复制的级联层次，同一个变动传到最底层的Slave所须要通过的MySQL也会更多，一样可能形成延时较长的风险。

而若是咱们经过分拆集群的方式来解决的话，可能就会要好不少了，固然，分拆集群也须要更复杂的技术和更复杂的应用系统架构。

 

 

dualMaster与级联复制结合架构(Master-Master-Slaves)

级联复制在必定程度上面确实解决了Master由于所附属的Slave过多而成为瓶颈的问题，可是他并不能解决人工维护和出现异常须要切换后可能存 在从新搭建Replication的问题。这样就很天然的引伸出了DualMaster与级联复制结合的Replication架构，我称之为 Master-Master-Slaves架构

和Master-Slaves-Slaves架构相比，区别仅仅只是将第一级Slave集群换成了一台单独的Master，做为备用Master，而后再从这个备用的Master进行复制到一个Slave集群。下面的图片更清晰的展现了这个架构的组成：

这种DualMaster与级联复制结合的架构，最大的好处就是既能够避免主Master的写入操做不会受到Slave集群的复制所带来的影响，同 时主Master须要切换的时候也基本上不会出现重搭Replication的状况。可是，这个架构也有一个弊端，那就是备用的Master有可能成为瓶 颈，由于若是后面的Slave集群比较大的话，备用Master可能会由于过多的SlaveIO线程请求而成为瓶颈。固然，该备用Master不提供任何 的读服务的时候，瓶颈出现的可能性并非特别高，若是出现瓶颈，也能够在备用Master后面再次进行级联复制，架设多层Slave集群。固然，级联复制 的级别越多，Slave集群可能出现的数据延时也会更为明显，因此考虑使用多层级联复制以前，也须要评估数据延时对应用系统的影响。

转自: http://www.cnblogs.com/ggjucheng/archive/2012/11/13/2768879.html