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进行分担),写压力较小。
架构图:
![](https://pic002.cnblogs.com/images/2012/428519/2012071721120985.jpg)
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切换进行维护、升级、改造的场景。
架构图:
![](https://pic002.cnblogs.com/images/2012/428519/2012071721124527.jpg)
上面的四种架构并不是一成不变的,需要结合业务场景进行选择,或定制化。毕竟,适合业务的设计才是最好的设计。
参考文献:
1.《MySQL性能调优与架构设计》
2.《MySQL 5.1参考手册》