《高性能MySQL》---- 复制

一、复制概述

MySQL支持两种复制方式：基于行的复制和基于语句的复制。复制通常不会增加主库的开销，主要是启用二进制日志带来的开销，但出于备份或及时从崩溃中恢复的目的，这点开销也是必要的。

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

当使用一主库多备库的架构时，可能会造成一些浪费，因为本质上它会复制大量不必要的重复数据。例如，对于一台主库和10台备库，会有11份数据拷贝。这不是一种经济的硬件使用方式，但这种复制架构却很常见，本章我们将讨论解决这个问题的方法。

二、复制解决的问题

下面是复制比较常见的用途：

• 数据分布
• 负载均衡
• 备份
• 高可用性和故障切换
• MySQL升级测试

三、复制如何工作

总的来说，复制有三个步骤：

1. 在主库上把数据更改记录到二进制日志(Binary Log)中(这些记录被称为二进制日志事件)。
2. 备库将主库上的日志复制到自己的中继日志(Relay Log)中。
3. 备库读取中继日志中的事件,将其重放到备库数据之上。

以上只是概述，实际上每一步都很复杂，图10-1更详细地描述了复制的细节。

这种复制架构实现了获取事件和重放事件的解耦，允许这两个过程异步进行。也就是说I/O线程能够独立于SQL线程之外工作。但这种架构也限制了复制的过程，其中最重要的一点是在主库上并发运行的查询在备库只能串行化执行，因为只有一个SQL线程来重放中继日志中的事件。后面我们将会看到，这是很多工作负载的性能瓶颈所在。

四、复制的原理

1、基于语句的复制

在MySQL 5.0及之前的版本中只支持基于语句的复制(也称为逻辑复制)，这在数据库领域是很少见的。基于语句的复制模式下，主库会记录那些造成数据更改的查询，当备库读取并重放这些事件时，实际上只是把主库上执行过的SQL再执行一遍。

优点：

• 实现简单
• 当主备的模式不同时，逻辑复制能够在多种情况下工作。
• 基于语句的方式执行复制的过程基本上就是执行SQL语句。这意味着所有在服务器上发生的变更都以一种容易理解的方式运行。这样当出现问题时可以很好地去定位。

缺点：

• 有些情况无法正确复制
• 更新必须是串行的

2、基于行的复制

MySQL 5.1开始支持基于行的复制，这种方式会将实际数据记录在二进制日志中，跟其他数据库的实现比较相像。最大的好处是可以正确地复制每一行。一些语句可以被更加有效地复制。

由于无须重放更新主库数据的查询，使用基于行的复制模式能够更高效地复制数据。重放一些查询的代价可能会很高。

优点：

• 几乎没有基于行的复制模式无法处理的场景。
• 可能减少锁的使用，因为它并不要求这种强串行化是可重复的。
• 基于行的复制模式会记录数据变更，因此在二进制日志中记录的都是实际上在主库上发生了变化的数据。你不需要查看一条语句去猜测它到底修改了哪些数据。 另外在一些情况下基于行的二进制日志还会记录发生改变之前的数据，因此这可能有利于某些数据恢复。
• 在很多情况下，由于无须像基于语句的复制那样需要为查询建立执行计划并执行查询，因此基于行的复制占用更少的CPU。
• 在某些情况下，基于行的复制能够帮助更快地找到并解决数据不一致的情况。

缺点：

• 由于语句并没有在日志里记录，因此无法判断执行了哪些SQL，除了需要知道行的变化外，这在很多情况下也很重要(这可能在未来的MySQL版本中被修复)。

3、总结

由于没有哪种模式对所有情况都是完美的，MySQL能够在这两种复制模式间动态切换。默认情况下使用的是基于语句的复制方式，但如果发现语句无法被正确地复制，就切换到基于行的复制模式。还可以根据需要来设置会话级别的变量binlogformat，控制二进制日志格式。

五、复制拓扑结构

记住下面的基本原则：

• 一个MySQL备库实例只能有一个主库。
• 每个备库必须有一个唯一的服务器ID。
• 一个主库可以有多个备库(或者相应的,一个备库可以有多个兄弟备库)。
• 如果打开了log-slave-updates选项，一个备库可以把其主库上的数据变化传播到其他备库。

1、一主库多备库

这是最简单的拓扑结构。在有少量写和大量读时，这种配置是非常有用的。
这种结构流行的原因是它避免了很多其他拓扑结构的复杂性。

尽管这是非常简单的拓扑结构，但它非常灵活，能满足多种需求。下面是它的一些用途：

• 为不同的角色使用不同的备库(例如添加不同的索引或使用不同的存储引擎)。
• 把一台备库当作待用的主库，除了复制没有其他数据传输。
• 将一台备库放到远程数据中心，用作灾难恢复。
• 延迟一个或多个备库，以备灾难恢复。
• 使用其中一个备库，作为备份、培训、开发或者测试使用服务器。

2、主动-主动模式下的主-主复制

主-主复制(也叫双主复制或双向复制)包含两台服务器，每一个都被配置成对方的主库和备库，换句话说，它们是一对主库。图10-5显示了该结构。

这种配置最大的问题是如何解决冲突，两个可写的互主服务器导致的问题非常多。

3、主动-被动模式下的主-主复制

这是前面描述的主-主结构的变体，它能够避免主-主复制写冲突问题。这也是构建容错性和高可用性系统的非常强大的方式，主要区别在于其中的一台服务器是只读的被动服务器，如图10-7所示。

这种方式使得反复切换主动和被动服务器非常方便，因为服务器的配置是对称的。这使得故障转移和故障恢复很容易。它也可以让你在不关闭服务器的情况下执行维护、优化表、升级操作系统(或者应用程序、硬件等)或其他任务。

4、拥有备库的主-主结构

外一种相关的配置是为每个主库增加一个备库，如图10-8所示。

这种配置的优点是增加了冗余，对于不同地理位置的复制拓扑，能够消除站点单点失效的问题。你也可以像平常一样，将读查询分配到备库上。

5、环形复制

如图10-9所示，双主结构实际上是环形结构的一种特例。环形结构可以有三个或更多的主库。每个服务器都是在它之前的服务器的备库，是在它之后的服务器的主库。这种结构也称为环形复制(circular replication)。

环形结构没有双主结构的一些优点，例如对称配置和简单的故障转移，并且完全依赖于环上的每一个可用节点，这大大增加了整个系统失效的几率。总地来说，环形结构非常脆弱,应该尽量避免。

可以通过为每个节点增加备库的方式来减少环形复制的风险，如图10-10所示。但这仅仅防范了服务器失效的危险，断电或者其他一些影响到网络连接的问题都可能破坏整个环。

6、主库、分发主库以及备库

我们之前提到当备库足够多时,会对主库造成很大的负载。每个备库会在主库上创建一个线程，并执行binlog dump命令。该命令会读取二进制日志文件中的数据并将其发送给备库。每个备库都会重复这样的工作，它们不会共享binlog dump的资源。

因此，如果需要多个备库，一个好办法是从主库移除负载并使用分发主库。分发主库事实上也是一个备库，它的唯一目的就是提取和提供主库的二进制日志。多个备库连接到分发主库，这使原来的主库摆脱了负担。为了避免在分发主库上做实际的查询，可以将它的表修改为blackhole存储引擎,如图10-11所示。

7、树或金字塔形

如果正在将主库复制到大量的备库中。不管是把数据分发到不同的地方，还是提供更高的读性能，使用金字塔结构都能够更好地管理，如图10-12所示。

这种设计的好处是减轻了主库的负担，就像前一节提到的分发主库一样。它的缺点是中司层出现的任何错误都会影响到多个服务器。如果每个备库和主库直接相连就不会存在这样的问题。同样，中间层次越多，处理故障会更困难、更复杂。

六、定制的复制方案

1、选择性复制

为了利用访问局部性原理(locality of reference)，并将需要读的工作集驻留在内存中，可以复制少量数据到备库中。如果每个备库只拥有主库的一部分数据，并且将读分配给备库，就可以更好地利用备库的内存。并且每个备库也只有主库一部分的写入负载，这样主库的能力更强并能保证备库延迟。

2、只读备库

许多机构选择将备库设置为只读，以防止在备库进行的无意识修改导致复制中断。可以通过设置read_only选项来实现。它会禁止大部分写操作，除了复制线程和拥有超级权限的用户以及临时表操作。只要不给也不应该给普通用户超级权限，这应该是很完美的方法。