MySQL复制之理论篇

Posted 2020-09-03 编程人，在天涯

一、mysql复制概述

　　MySQL支持两种复制方式：基于行的复制和基于语句的复制（逻辑复制）。这两种方式都是通过在主库上记录二进制日志、在备库重放日志的方式来实现异步的数据复制，其工作原理如下图：

　　同一时间点主库和备库的数据可能存在不一致。复制通常不会增加主库的开销，主要是启用二进制日志带来的开销。通过复制可以将读操作指向备库来获得更好的读扩展，但对于写操作，除非设计得当，否则并不适合通过复制来扩展写操作。在一主库多备库的架构中，写操作会被执行多次，这时候整个系统的性能取决于写入最慢的那部分。

　　复制解决的问题（用途）：数据分布、负载均衡、备份、高可用性和故障切换、MySQL升级测试等等。

 

二、MySQL复制原理

1. 基于语句的复制：

　　主库记录那些造成数据更改的查询，当备库读取并重放这些事件时，实际上只是把主库上执行过的SQL再执行一遍。

好处：实现简单、二进制日志里事件更加紧凑。当主备库模式不同时，逻辑复制能在多种情况下工作。容易理解，出现问题可以很好定位。

缺点：存在一些无法被正确复制的SQL，例如当使用了CURRENT_USER()函数时。更新必须是串行的，这需要更多的锁。存储过程和触发器在使用基于语句的复制模式时也可能存在问题。

2. 基于行的复制：
　　基于行的复制将实际数据记录在二进制日志中。

好处：可以正确地复制每一行。无须重放更新主库数据的查询，更高效。减少锁的使用。

缺点：很难进行时间点恢复、开销有时大有时小。无法判断执行了哪些SQL。出现问题很难定位。无法处理诸如在备库修改表的schema这样的情况。

　　没有哪种模式对所有情况都是完美的，MySQL能够在这两种复制模式间动态切换。默认情况下使用的是基于语句的复制方式，但如果发现语句无法被正确地复制，就切换到基于行的复制模式。

3. 复制使用的文件：

（1）二进制日志文件、中继二进制日志文件（文件名可在mysql配置文件中配置）

（2）mysql-bin.index：记录所有的二进制日志文件名，不能删除，MySQL依赖这个文件识别二进制日志文件。

（3）mysql-relay-bin.index：记录所有中继日志的索引文件，同样不能删除。

（4）master.info：保存备库连接到主库所需要的信息，格式为纯文本，记录了复制用户的密码。

（5）relay-log.info：记录当前备库复制的二进制日志和中继日志坐标。

4. 发送制事件到其他备库：

　　log_slave_updates选项可以让备库变成其他服务器的主库。在设置该选项后，MySQL会将其执行过的事件记录到它自己的二进制日志中，这样它的备库就可以从其日志中检索并执行事件。原理图如下：

注意：

　　当复制SQL线程读中继日志时，会丢弃事件中记录的服务器ID和该服务器本身ID相同的事件，从而打破了复制过程中的无限循环。

5. 复制过滤器：

　　复制过滤器选项允许仅复制服务器上一部分数据。有两种过滤方式：在主库上过滤记录到二进制日志中的事件、在备库上过滤记录到中继日志中的事件。原理图如下：

注意：

　　除非万不得已，不要使用复制过滤，因为它很容易中断复制并导致问题，在需要灾难恢复时也会带来极大的不方便。

 

三、复制拓扑
　　可以在任意个主库和备库之间建立复制，只有一个限制：每一个备库只能有一个主库。各种拓扑结构的基本原则：

（1）一个MySQL备库实例只能有一个主库。

（2）每个备库必须有一个唯一的服务器ID。

（3）一个主库可以有多个备库。

（4）如果打开了log_slave_updates选项，一个备库可以把其主库上的数据变化传播到其他备库。

1. 一主库多备库：

　　在有少量写和大量读时，这种配置是非常有用的。可以把读分摊到多个备库上，直到备库给主库造成了太大的负担，或者主备之间的带宽成为瓶颈为止。

2. 主动-主动模式下的主-主复制：
　　也叫双主复制或双向复制，包含两台服务器，每一个都被配置成对方的主库和备库。

　　这种配置最大的问题是如何解决冲突，例如，两台服务器同时修改一行记录，或同时在两台服务器上向一个包含auto_increment列的表里插入数据。

　　允许向两个服务器写入所带来的麻烦远远大于其带来的好处。

3. 主动-被动模式下的主-主复制：

　　把“主动-主动模式下的主-主复制”中的的一台服务器配置成只读的被动服务器。

　　这种方式使得反复切换主动和被动服务器非常方便，因为服务器的配置是对称的，这使得故障转移和故障恢复很容易。

4. 拥有备库的主-主结构：

　　为主-主复制中的每个主库增加一个备库。

　　这种配置的优点是增加了冗余，对于不同地理位置的复制拓扑结构，能够消除站点单点失效的问题。

5. 环形复制：
　　每个服务器都是在它之前的服务器的备库，是在它之后的服务器的主库。完全依赖于环上的每一个可用节点，大大增加了整个系统失效的几率。如果从环中移除一个节点，这个节点发起的事件就会陷入无限循环。

　　可用通过为每个节点增加备库的方式来减少环形复制的风险。

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

　　当备库足够多时，会对主库造成很大的负载。这种拓扑使用一个备库专门来进行复制的分发，移除主库的负载。

　　为了避免在分发主库上做实际的查询，可以将它的表修改为blackhole存储引擎。如果主库接近满负载，不应该为其建立10个以上的备库。可以通过设置slave_compressed_protocol来节约一些主库宽带。可以通过分发主库实现其他目的，例如对二进制日志事件执行过滤和重写规则。

　　使用分发主库一个主要的缺点是无法使用一个备库来代替主库，因为由于分发主库的存在，导致各个备库与原始主库的二进制日志坐标已经不相同。

7. 树或金字塔形：

　　减轻了主库的负担，但它的缺点是中间层出现的任何错误都会影响到多个服务器，中间层次越多，处理故障会越困难、越复杂。