MySQL内建的复制功能是构建基于MySQL的大规模、高性能应用的基础，这类应用使用所谓的“水平扩展” 的架构。我们可以通过为服务器配置一个或多个备库的方式来进行数据同步。复制功能不仅有利于构建高性能的应用，同时也是高可用性、可扩展性、灾难恢复、备份以及数据仓库等工作的基础。事实上，可扩展性和高可用性通常是相关联的话题。

        本章将阐述所有与复制相关的内容，首先简要介绍复制如何工作，然后讨论基本的复制服务搭建，包括与复制相关的配置以及如何管理和优化复制服务器。虽然本章的主题是高性能，但对于复制来说，我们同样需要关注其准确性和可靠性，因此我们也会讲述复制在什么情况下会失败，以及如何使其更好地工作。

复制概述

        复制解决的基本问题是让一台服务器的数据与其他服务器保持同步。一台主库的数据可以同步到多台备库上，备库本身也可以被配置成另外一台服务器的主库。 主库和备库之间可以有多种不同的组合方式。

        MySQL支持两种复制方式:基于行的复制和基于语句的复制。基于语句的复制(也称为逻辑复制)早在MySQL 3.23版本中就存在，而基干行的复制方式在5.1版本中才坡加进来。这两种方式都是通过在主库上记录二进制日志、在备库重放日志的方式来实现异步的数据复制。这意味着，在同一时间点备库上的数据可能与主库在不致、并且无法保证主备之间的延达。一些大的语句可能导致备库产生几秒、几分钟甚至几个小时的延迟。（注：可能有些地方将会复制备库(replica) 称为从(slave),这里我们尽量避免这种叫法。）

        MySQL复制大部分是向后兼容的，新版本的服务器可以作为老版本服务器的备库，但反过来，将老版本作为新版本服务器的备库通常是不可行的，因为它可能无法解析新版本所采用的新的特性成语法，另外所使用的二进制文件的格式也可能不相同。例如，不能从MySQL 5.1复制到MySQL 4.0。在进行大的版本升级前，例如从4.1 升级到5.0,或从5.1升级到s5.最好先对复制的设置进行测试。但对于小版本号升级，如从5.1.51升级到51.8.则通常是兼容的。通过阅读每次版本更新的ChangeLog可以找到不同版本间做了什么修改。

        复制通常不会增加主库的开销，主要是启用二进制日志带来的开销，但出于备份或及时从阳滑中恢复的目的，这点开销也是必要的。除此之外，每个备库也会对主库增加一些负载(例如网络I/O开销)，尤共当备库请求从主库读取旧的二进制日志文件时，可能会造成更高的I/O开销。另外锁竞争也可能阻碍事务的提交。最后，如果是从一个高吞吐量(例如5 000或更高的TPS)的主库上复制到多个备库，唤醒多个复制线程发送事件的开销将会累加。

        通过复制可以将读操作指向备库来获得更好的读扩展，但对于写操作，除非设计得当，否则并不适合通过复制来扩展写操作。在一主库多 备库的架构中，写操作会被执行多次，这时候整个系统的性能取决于写入最慢的那部分。

        当使用一主库多备库的架构时，可能会造成一些浪费，因为本质上它会复制大量不必要的重复数据。例如，对于一台主库和10台备库， 会有11份数据拷贝，并且这11台服务器的缓存中存储了大部分相同的数据。这和在服务器上有11路RAID 1类似。这不是一种经济的硬件使用方式，但这种复制架构却很常见。后续会为大家讲解解决这个问题的方法。