MySQL Replication可扩展设计

 在实际中，采用单机MySQL数据库的系统可能会随着数据量的不断增长，造成读写压力越来越大，效率越来越低，对外提供的服务也就越来越差。同时，由于没有冗余数据的存在，单机数据库的数据安全性也有潜在的隐患。因此，我们可以采用MySQL提供的replication方案来对系统进行升级改造，在提高数据安全性的同时，使系统具有良好的可扩展性。

 

   在这里也说一下 MySQL Cluster和MySQL replication的区别 ：

   MySQL Cluster：分布式的，同步的，操作在所有的机器上提交是同步的，所有机器上的数据是一致的；

   MySQL replication：异步的，master和salve可能数据不一致（因为复制是有延时的，并且不会撤销）。

 

    在讨论设计方案前，先简要介绍下 replication的实现原理：

    MySQL的replication是一个异步复制过程，从master向slave进行日志复制（因此必须打开master端binary log功能）。整个复制过程主要由三个线程完成，sql线程和一个IO线程在slave端，另一个IO线程在master端。复制过程简单地说，分为三步：

    1.slave端的IO线程向master请求日志。

    2.在收到slave的请求后，master端的IO线程读取日志信息，并返回给slave。

    3.slave端的sql线程对日志进行解析，然后执行和master端一样的操作。

    这样就使得slave端的数据是master端的一个镜像，提供了数据的冗余备份。当然，实际过程远比上面的描述复杂，可以参考mysql的官方文档，也可以阅读mysql的源码获取内部的具体秘密。

 

下面说说常用的 replication设计架构：   

1.Master-Slaves架构

  架构描述：使用一个master和一个或多个slave服务器，把master端的数据复制到一个或多个slave上。由于只存在单个master节点，因此对该master节过于依赖，无法进行master的切换。

  适用场景：读压力比较大的应用（可以由多个slave进行分担），写压力较小。

  架构图：

  　　

    

2.Master-Master架构

  架构描述：在该方案中，每个节点既充当master，也充当slave。当一个master有写操作执行时，数据也会复制到其他节点。

  适用场景：读写压力适中，master可能宕机或有需要进行master切换进行维护、升级、改造的场景。

  架构图：

　　

 

3.Master-Slaves-Slaves级联架构

 架构描述：在有些应用中，可能读写压力差别特别大，需要很多slave服务器来支撑读操作。因此单个master向很多slave的复制操作会延时比较大，而且master压力很大。改进方法是，master向第一级slave复制，第一级slave向第二级slave复制，依次下去。

 适用场景：读写压力相差特别大，需要很多slave服务器来承担读的压力。

 架构图：

　　

 

4.Dual Master与级联复制结合架构Master-Master-Slaves

    架构描述：该架构结合了Master-Master架构和Master-Slaves-Slaves架构的优点，减少了对单master节点的依赖，同时采用级联复制，减小了master的压力。

    适用场景：读写压力差别很大，master可能宕机或有需要进行master切换进行维护、升级、改造的场景。

    架构图：

  　　

 

    上面的四种架构并不是一成不变的，需要结合业务场景进行选择，或定制化。毕竟，适合业务的设计才是最好的设计。

 

参考文献：

1.《MySQL性能调优与架构设计》

2.《MySQL 5.1参考手册》