non-mysql_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参考手册》