- A+
MySQL内建的复制功能是构建基于MySQL的大规模、高性能应用的基础,这类应用使用所谓的“水平扩展”的架构。我们可以通过为服务器配置一个或者多个备库(从库)的方式来进行数据复制。复制功能不仅利于构建高性能的应用,同时也是高可用行、可扩展性、灾难恢复、备份以及数据仓库等工作的基础。我们将通过几篇文章来分别介绍复制的工作原理、基本的复制服务搭建和复制相关的配置以及如何管理和优化复制服务器。
一、复制概述
复制解决的基本问题是让一台服务器的数据与其他服务器保持同步。一台主库的数据可以同步到多台备库上,备库本身也可以被配置为另一台服务器的主库。
MySQL支持的复制方式有两种:基于行的复制和基于语句的复制。这两种方式都是通过在主库上记录二进制日志、在备库重放日志的方式来实现异步的数据复制。这意味着,在同一时间点备库上的数据可能与主库存在不一致,并且无法保证主备之间的延迟。一些大的语句可能导致备库产生几秒、几分钟甚至几个小时的延迟。
复制通常不会增加主库的开销,主要是启用二进制文件日志带来的开销,但出于备份或者及时从崩溃中恢复的目的,这点开销也是必要的。
二、复制解决的问题
复制场景的用途:
数据分布
MySQL复制通常不会对带宽造成很大的压力,但在MySQL5.1引入的基于行的复制会比传统的基于语句的复制模式带来的带宽压力更大。
负载均衡
通过MySQL复制可以将读操作分布到多个服务器上,实现对密集型应用的优化,并且实现很方便,可以通过简单的代码修改就可以实现基本的负载均衡。
备份
对于备份来说,复制是一项很有意义的补充,但复制不是备份也不能取代备份。
高可用性和故障切换
复制能够帮助应用程序避免MySQL单点失败,一个包含复制的设计良好的故障切换系统能够显著的缩短宕机时间。
MySQL升级测试
这种做法比较普遍,使用一个高版本的MySQL作为备库,保证在升级全部实例前,查询能够在备库按照预期执行。
三、复制的工作原理
复制主要分为三个步骤:
-
在主库上把数据更改记录到二进制文件(Binary Log)中(这些记录被称为二进制日志事件)。
-
备库将主库上的日志复制到自己的中继日志(Relay Log)中。
-
备库读取中继日志中的事件,将其重放到备库的数据之上。