这是可靠数据库所应具备的几个特性.
业务拆分不仅提高了系统的可拓展性,而且还提高了开发工作的效率。原来一次修改,工程的启动和部署都需要花费较大的时间成本。随着系统的拆分,单个系统的复杂度降低,减轻了应用多个分支合并冲突解决的麻烦,不仅大大提高了研发测试效率,同时也提高了系统的稳定性。
通过数据库的复制策略,可以将一台数据库服务器中的数据复制到另一台数据库服务器中。当各台数据库服务器上都包含相同的数据时,前端应用通过访问MySQL集群中的任一一台数据库服务器,都可以读取到想要的数据,这样单独一台数据库服务器所承担的压力就会大大降低,从而提高系统的承载能力,达到系统拓展的目的。
如图所示,要实现MySQL的主从复制策略,需要开启Master服务器端的Binary Log,数据的复制过程实际上就是Slave从Master获取Binary log,然后在本地镜像中执行Binary log中记录的操作的一个过程。
由于复制的过程是异步的,因此Master和Slave之间的数据可能出现延迟现象,此时只能保证最终数据的一致性。
MySQL的复制可以是基于statement level(基于语句),也可以row level(基于记录) 。
基于row level的复制,可以不记录Sql语句的上下文信息,只需记录数据变更的内容即可,但是由于每行的变更记录都会被记录,这样可能会产生很多的日志内容。
基于statement level的复制,则值记录修改数据的Sql语句 ,减少了Binary log的日志量,解决了I/O成本,但是为了保证SQL能够在Slave上正确的执行,它还需要记录SQL的上下文信息,以保证SQL在Slave上执行的结果与在Master上执行的结果一致。
如图,在实际的应用场景中,MySQL的Master与Slave之间的复制架构可能是这样的。
前端服务器通过Master来执行写操作,数据更新通过Binary log同步到Slave集群,而对于数据的读取请求,则交由Slave来处理。这样Slave集群就分担了数据库的读压力,并且读写分离还保障了数据能够达到最终的数据一致性。
一般情况下,大多数网站的读操作会比写操作更为密集,如果读的压力比较大时,可以通过增加Slave来进行系统的拓展,因此,Master-Slave架构能够很显著的提高系统性能,减轻单个数据库的读压力。
但是Master-Slave架构也存在一个致命的问题,那就是单点故障的问题。当Master宕机之后,系统将无法进行写操作,但是在某些特定的环境下,也可能需要Master停机,以便进行系统的维护和升级。
怎么解决这个问题,在MySQL中,可以采用Master-Master的架构去解决Master单点故障的问题,我们下一篇文章再讲述。