MySQL 5.6 复制介绍

1、介绍

MySQL复制使得用户能够经济高效地提高应用性能、可扩展性以及高可用性。许多全球流量最大的网站，例如eBay、Facebook、Tumblr、Twitter以及YouTube，依赖MySQL复制轻松地扩展，超越单实例容量的限制，支持了数亿、呈指数增长的用户。

通过在实例之间镜像数据，MySQL复制也是实现MySQL数据库高可用性（HA）最常用的方法。此外，MySQL复制工具能够自动检测和恢复失败，使得用户能够在故障或者计划维护时维持服务。

MySQL 5.6引入了许多复制增强功能，实现了更高级别的数据完整性、性能、自动化以及应用灵活性。本文将会讨论这些增强功能。

本文还将探讨部署MySQL复制的商业和技术优势，并说明复制背后的技术原理。

本文最后概括了MySQL复制与MySQL集群数据库的主要差异。

另一篇文章（MySQL 5.6复制教程）提供了一个简单的关于如何安装和配置主从复制拓扑结构，以及故障转移事件的逐步操作指南。它演示了如何使用全局事务ID（GTIDs）完成这些操作，以及采用更加传统的方法时所需的额外步骤。

2、复制原理

本文中的“复制”定义为一个或者多个地点的数据冗余，可以在一个数据中心内，也可以是地理上分布的复制。在下面的章节中将会讨论不同的复制类型的区别。

复制将数据库的变化从一个位置或者系统拷贝或复制到另一个位置或者系统中（通常从主服务器到从服务器）。这通常是用于提供数据库的可用性和可伸缩性，虽然用户经常也会在从服务器上执行备份操作或者分析查询，从而减轻主服务器的这些负载。

MySQL将复制作为一个数据库标准特性，提供内置支持。根据配置的不同，可以复制所有的数据库，指定的数据库，甚至是数据库内指定的表。

MySQL复制只使用一个主服务器，以及一个或者多个从服务器。主服务器记录数据库的变化，然后将变化发送并应用到从服务器。

图1 MySQL复制支持“开箱即用”的HA和可伸缩性读

使用MySQL复制为以数据库写操作（SELECT）为主的大型网站提供横向扩展的能力。从服务器占用非常少的主服务器性能消耗（通常每个从服务器1%的消耗），许多大型门户网站的每个主服务器部署了30多个从服务器。

2.1、复制模式与数据一致性

复制存在多种模式，定义为异步复制、半同步复制以及同步复制。

图2 不同复制模式对比

异步复制

MySQL默认使用异步复制。更新提交到主服务器数据库，然后转发并应用到从服务器。主服务器不需要等待从服务器接收到更新，因此能够继续处理其他写入操作，不会因为等待从服务器的确认而被阻塞。

使用异步复制时，发生主服务器故障的情况下，不能保证所有的更新能够复制到从服务器。下面讨论的半同步复制能够增强主服务器与从服务器之间的数据一致性，降低故障转移时的数据丢失风险。

对于存在大量写入操作的高事务应用，从服务器明显会存在已提交更新的延迟（滞后）。

使用正确的组件和调优，复制对于应用而言可以是近似接近即时的。

使用异步复制，从服务器从主服务器接收更新时不需要永久性连接。这意味着可以通过长距离的连接，甚至临时的或者间断的连接进行更新。根据配置的不同，可以复制所有的数据库，指定的数据库，甚至是数据库内指定的表。

半同步复制

半同步复制可以作为默认的异步复制的替代方案，用以提高数据完整性。

使用半同步复制，提交操作只有当一个从服务器已经接收到更新，或者超时后才返回客户端。因此，它可以确保数据存在于主服务器以及至少一个从服务器中（注意，提交操作返回时，从服务器已经接收到更新，但不一定已经应用了该更新）。

可以组合使用不同的复制模式，因此一些从服务器配置为异步复制，而其他从服务器使用半同步复制。这样最终意味着开发人员/DBA能够基于每个从服务器确定合适的数据一致性和性能级别。

以上描述的不同复制模式可以与完全同步复制进行比较，后者使用“两阶段提交”协议同时将数据提交到两个或者更多实例中。同步复制能够确保多个系统之间的一致性，故障时提供更快的故障转移时间，但是会因为在节点之间传递更多的消息导致性能消耗。

2.2、基于语句的复制

MySQL默认使用基于语句的复制，将SQL语句（而不是实际的数据变化）从主服务器复制到从服务器。

基于语句的复制的一个优点就是在某些情况下，最终写入日志文件的数据更少，例如更新或者删除许多行时。对于只影响几行数据的简单语句，基于行的复制占用的空间更少。

基于语句的复制也存在一些缺点，最明显的是它不支持不确定性的语句，例如当前时间函数。

2.3、基于行的复制

基于行的复制使用单个的表行记录变化，而不是语句。主服务器将消息，也就是事件写入二进制日志，表示单个表行的变化。这与其他RDBMS中更加传统的复制方式类似。总之，基于行的复制需要更少的锁定，意味着能够达到更高的并发。基于行的复制的一个缺点就是它会产生更多需要记录的数据。例如，如果一个语句修改了表的100行，意味着使用基于行的复制需要记录100个变化，而是要基于语句的复制只需要复制单个SQL语句。

需要注意的是，增强MySQL复制的开发工作集中在RBR而不是SBR，因此建议使用RBR，除非存在无法控制的原因。

如果使用MySQL集群，必须使用基于行的复制。

2.4、混合模式复制

使用混合模式日志，可以根据要记录的事件实时改变二进制日志格式。使用混合模式复制时，默认采用基于语句的复制，但是在某些情况下自动切换到基于行的复制，例如：

更新MySQL簇表的DML语句

包含UUID( )的语句

更新两个或多个使用AUTO_INCREMENT列的表

执行任何INSERT DELAYED语句

当视图需要基于行的复制，创建视图的语句同样适用基于行的复制。例如，使用UUID( )函数创建视图的语句

调用用户定义的函数

访问以下地址查看完整的条件列表：http://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html。

3、MySQL 5.6复制变化总结

MySQL 5.6引入了历次发表以来最重要的一组复制增强功能。

这些增强功能提供了以下好处：

高性能

改善了从服务器的读一致性（例如，减少了读取“陈旧”数据的风险）

减少了主服务器在复制全部二进制日志事件之前崩溃时数据丢失的风险

高可用性

通过使用GTIDs简化了故障转移

复制拓扑的前摄式监控，在可能引起停机之前定位问题

数据完整性

确保被复制数据的正确性、一致性以及可访问性

开发/操作（DevOps）灵活性

自动化以减少管理开销

支持快速发展的业务需求的灵活性

保持较低的总体拥有成本（TCO）

下面详细讨论这些增强功能。

3.1、使用MySQL复制和GTIDs实现HA

最重要的HA增强就是引入了全局事务标识符（GTIDs）。引入GTIDs主要的目的是支持无缝故障转移和正常切换，最小化人工干预和服务的中断。GTIDs是由服务器UUID（原始主服务器）和一个事务编码组成的唯一标识符。它们作为每个事务的头部信息自动生成，并随事务一起写入二进制日志中。GTIDs简化了在主服务器和从服务器之间追踪和比较被复制的事务，从而使得主服务器失败时的恢复更加简单。默认的InnoDB存储引擎必须与GTIDs一起使用以获得HA的全部优点。

全局事务标识符（GTIDs）

为了理解GTIDs的实现和功能，下文使用一个最常见的复制拓扑，一个主服务器（A）接收所有的更新，并将更新复制到一个或者多个从服务器中（B和C）。这个结构通常简称为“主/从复制”或者“树状拓扑”，如图3所示。

图3 简单的主/从拓扑

如果服务器A崩溃，需要转移至某个从服务器，将它提升为主服务器，而剩余的服务器作为新的主服务器的从服务器，如图4所示。

图4 主服务器故障与从服务器提升

因为MySQL复制默认采用异步方式，服务器B和服务器C可能没有复制和执行了相同的事务集，也就是说，某个服务器可能完成了更多的复制。考虑以下场景：

服务器B比C执行了更多的复制，并且B被选择为新的主服务器。服务器C需要从服务器B中复制还没有复制到C的事务

服务器C可能执行了服务器B没有接收到的事务。此时，服务器B需要在设定为主服务器之前从服务器C中接收任何缺少的事务，否则可能丢失事务和产生冲突

GTIDs为每个事务赋予一个唯一标识符，因此很容易在每个从服务器上追踪。当主服务器提交一个事务时，将会产生一个由以下两部分组成的GTID：

第一部分是服务器的UUID（一个随机生成的128比特的数字）

第二部分是一个自动增长的整数；服务器第一个提交的事务为1，第二个事务为2，等等

第一部分能够保证不同服务器产生的两个事务拥有不同的GTIDs。第二部分能够保证同一个服务器产生的两个事务拥有不同的GTIDs。

GTIDs的ASCII格式为“UUID:N”，例如22096C54-FE03-4B44-95E7-BD3C4400AF21:4711。

GTID在事务之前被写入二进制日志，如图5所示。

图5 二进制日志中的GTID位置

GTID与事务一起被复制到从服务器。如果从服务器配置了将变更写入它自己的二进制日志，从服务器确保在事务提交后保留并写入GTID和事务。

重要的是要注意从服务器不会产生新的GTID，即使该从服务器在n层复制拓扑（分层或者级联）中配置为其他从服务器的主服务器。

在每个从服务器上执行的GTIDs集通过一个新的全局只读服务器变量，gtid_executed，展示给用户。该变量可以与GTID_SUBSTRACT( )一起使用，判断从服务器是否追赶上了主服务器；如果没有追赶上，显示缺少了哪些事务。

MySQL创建了一个新的复制协议以自动化以上过程。当从服务器连接到主服务器时，该协议确保将从服务器已经执行和提交的GITDs范围发送到主服务器，并请求缺少了事务。主服务器随后将全部其他的事务，也就是从服务器还没有执行的事务，发送给从服务器。如图6所示。

图6 自动同步新的主服务器与从服务器

在本例中，服务器B在服务器A崩溃之前执行了所有的事务。通过MySQL复制协议，服务器C将会发送“id1”到服务器B，然后B将“id2”和“id3”发送到C，然后再复制提交的新事务。

如果互换角色并且服务器C早于服务器B，同样的过程将会确保服务器B能够接收到还没有执行的事务，然后提升为新的主服务器。

因此，MySQL拥有一个提升从服务器的可靠基础，确保主服务器故障时不会丢失已经在从服务器上执行的任何事务。

简化复制的工具

为了便于使用，MySQL复制提供了额外的工具用以加速实现新的复制集群。

图7 使用MySQL复制工具快速实现复制集群

这些支持故障转移和恢复的工具是更广泛的MySQL工具套件的一部分，工具套件能够简化MySQL服务器的维护与管理，包括复制的实现和验证，数据库的比较和克隆，诊断等等。这些工具使用GPLv2许可，并且可以通过提供的库进行扩展。使用这些工具需要Python 2.7或者以上版本。源代码可以从https://launchpad.net/mysql-utilities获取。

图8 在MySQL Workbench中启动MySQL工具

复制工具：mysqlreplicate

该工具用于启动复制过程，能够快速简单地引入复制从服务器。用户提供登录和连接主服务器的参数，以及可选的二进制日志复制起点。任何已经在从服务器上执行过的GTIDs将会被跳过。该工具还会检查存储引擎的兼容性。

复制工具：mysqlrplcheck

提供简单的部署验证和快速的故障排除。该工具检查是否启用二进制日志，并且显示配置异常。然后检查从服务器到主服务器的访问和权限，以及从服务器连接状态。每个测试按照顺序执行，并且生成状态报告。

以下是一个输出示例：

$ mysqlrplcheck --master=root@host1:3310

--slave=root@host2:3311

# master on host1: ... connected.

# slave on host2: ... connected. Test Description Status

-------------------------------------------------------------

Checking for binary logging on master [pass]

Are there binlog exceptions? [pass]

Replication user exists? [pass]

Checking server_id values [pass]

Is slave connected to master? [pass]

Check master information file [pass]

Checking InnoDB compatibility [pass]

Checking storage engines compatibility [pass]

Checking lower_case_table_names settings [pass]

Checking slave delay (seconds behind master) [pass]

# ...done.

复制工具：mysqlrplshow

按需查找并显示复制拓扑。显示连接到每个主服务器的从服务器，并且使用主机名和端口号标记从服务器。

复制工具：mysqlfailover

该工具提供连续的复制拓扑监控，在主服务器故障时允许自动或者手动的故障转移。默认按照以下的选举标准提升最可行的从服务器。

从服务器正在运行并且可达

从服务器启用了GTIDs

该从服务器已复制的事务最多

从服务器的复制过滤器不存在冲突

复制用户存在

启用了二进制日志

一旦选定了一个可行的从服务器（候选者），就会开始检索复制集群中所有的活动事务。候选从服务器连接到剩余的从服务器，然后获取缺少的事务。这样能够确保不会丢失已经复制的事务。

选举过程可以配置。管理员可以使用一个列表指定候选从服务器组（例如，那些硬件性能更好的服务器）。

启动该工具时，用户可以指定一个从服务器列表或者提供一个用于查找从服务器的默认的用户名和密码。用户可以在这个列表中指定一个候选从服务器子集。

该工具从一个单独的主机连接到主服务器和从服务器。在n层环境中，可以为每个主服务器运行一个实例。该工具能够运行关于主服务器和从服务器的故障转移检查和健康报告，从间隔5秒钟开始，每次执行间隔递增1秒。

复制工具：mysqlrpladmin

如果用户因为计划维护需要将主服务器脱机，该工具可以执行到指定从服务器（新的主服务器）的正常切换。执行正常切换时，旧的主服务器将被锁定，所有的从服务器能够追赶复制。当从服务器读取了旧的主服务器上的全部事件，旧的主服务器将被关闭，并且控制切换到新的主服务器。

多线程从服务器

使用多个执行线程应用复制事件到从服务器可以提高复制性能。

图9 多线程从服务器设计

如图9所示，多线程从服务器基于模式在工作线程之间分配操作，允许并行而不是顺序应用更新。这对于那些使用多个数据库分隔应用数据的系统能够提供效率，例如多租户系统。分配操作在读取中继日志中的复制事件时进行。工作线程的数量使用参数slave-parallel-workers配置（默认值为0，表示关闭该功能）。

为了证明多线程从服务器的性能优势，MySQL工程团队运行了一个基准测试，比较了使用单线程复制和多线程复制时的吞吐量。结果如图10所示，基于10个数据库/模式的配置，从服务器吞吐量以5倍增加，改进了读一致性和减少了主服务器故障时的数据丢失风险。

图10 多线程从服务器基准测试

从服务器能够更快地追赶主服务器，因此用户不太可能需要控制持续的写入操作，正因为如此，从服务器不会落后地越来越远（这时，某些用户不得不减少系统的容量以减少从服务器滞后）。

3.2、二进制日志分组提交

二进制日志分组提交的引入显著地提高了复制性能，它通过按组写入二进制日志，而不是每次写入一条，减少了写入磁盘的频率。

这一改进极大地提高了复制主服务器的性能，如图11中的基准测试结果所示。

图11 二进制日志分组提交基准测试

参数sync_binlog用于控制刷新磁盘的频率，默认值0表示操作系统决定何时刷新，而值1的结果是每次事务之后刷新磁盘，更大的值表示分组写入。

3.3、优化的基于行的复制

该特性是基于行的复制的优化。通过只复制行映像中被INSERT、UPDATE以及DELETE操作更改的部分，主服务器和从服务器的复制吞吐量都能够得到提升，同时二进制日志磁盘空间、网络资源以及服务器内存占用都有所减少。

该功能通过binlog-row-image参数控制，可以设置为以下值：

full 包含完整的前映像和后映像。该值匹配早期版本方式，并且是默认设置

minimal 只记录变化的列，以及用于标识行的列

noblob 记录所有的列，除了不需要的BLOB和TEXT列之外

3.4、崩溃安全的复制

崩溃安全的复制，也就是事务复制，通过崩溃安全的从服务器和二进制日志扩展了MYSQL复制的健壮性、可用性以及易用性。

如图12所示，二进制日志位置信息和表数据能够作为同一事务的一部分写入，确保了使用InnoDB时它们是事务一致性的。这使得从服务器能够不需要管理员干预，将复制自动回滚到崩溃之前的最后一个已提交事件，并继续复制过程。这样不仅减少了操作，同时消除了从服务器失败引起的数据丢失和损坏。

图12 表数据与二进制日志的事务一致性

如果主服务器崩溃引起二进制日志的损坏，服务器会将日志自动恢复到能够正确读取的位置。

该功能通过将参数master-info-repository和relay-log-info-repository设置为TRUE来启用。

3.5、复制事件校验和

复制环境中的数据完整性确保了数据的正确、一致与可访问。

复制事件校验和通过检测数据损坏并返回错误，阻止从服务器损坏确保被复制的数据的完整性。

写入二进制日志和中继日志的校验和可以在不同的位置进行检测，能够检测内存、磁盘或者网络失败，或者数据库自身引起的错误。校验和可以基于每个从服务器实现，实现了如何以及何处配置的最大灵活性。

可以使用配置参数binlog-checksum，master-verify-checksum和slave-sqlverify-checksum控制是否生成校验和（并记录在二进制日志中）以及在何处执行验证，如图13所示。如果校验和包含在主服务器的二进制日志中，从服务器接收到复制事件时总是会执行验证。

图13 复制校验和

如果检测到了不匹配，复制将会停止，以便DBA能够修复问题并重新开始复制。

3.6、延时复制

延时复制为主服务器上的操作错误提供了保护，例如意外删除了表。延时复制允许在错误传播到所有从服务器之前暂停复制，转而允许从从服务器恢复丢失的数据。这样还可以不需要重新装载备份即可检查数据库的状态。

用户可以定义一个事件从主服务器复制到每个从服务器的时间延迟，以1秒为增量，最大为68年。这个设置可以使用CHANGE MASTER命令的MASTER_DELAY参数。

延时复制基于每个从服务器实现（通过控制SQL_THREAD的执行），因此用户可以配置多个从服务器立即应用复制事件，其他从服务器只在10分钟（例如）延迟后应用，从而提供了部署的灵活性，如图14所示。需要注意的是，从服务器仍然尽可能实时地接收复制事件，延迟应用在从中继日志中读取事件的时候。

图14 一个从服务器上的延时复制

4、复制用例

存在各种技术和业务的原因需要将数据从一个MySQL服务器复制到另一个。本节将会研究可以采用MySQL复制的各种使用案例和应用场景。

4.1、横向扩展

这是用户实现复制的最常见的理由。在横向扩展拓扑中，主要目标是在一个或者多个从服务器之间分担负载，以提高性能。

用户可以很容易地在商业硬件上创建数据库的多重复制，灵活地进行横向扩展以超越单实例的容量限制，以应对快速增长的数据库负荷。

这种方式与纵向扩展相反，后者的方式是增加现有机器的资源（通常是RAM和CPU）。纵向扩展可以看作一种满足容量增加需求的垂直的，“叉车”式方法。

在横向扩展结构中，读写操作在主服务器和从服务器之间进行分离。

图15 MySQL复制的横向扩展

具体来说，所有的写操作（UPDATE、INSERT、DELETE）发送到主服务器执行，读操作（SELECT）指向从服务器。这样使得之前在主服务器上执行的读操作负载转而使用从服务器上的可用资源。这样使得资源的利用更加高效，因为负载有效地分布到了多个服务器上。

读写分离可以在系统的不同层面进行处理，例如在应用内部（应用维护到所有数据库的连接并决定何时使用主服务器连接或者某个从服务器连接）或者在数据库连接器中。

假如使用MySQL的JDBC连接器（Connector/J），连接到数据库时可以在连接串中提供多个服务器，从主服务器开始，后面跟着从服务器。如果使用图16中所示的配置（“black”是主服务器，“blue”和“green”是从服务器），应用程序可以使用以下连接串连接到数据库“clusterdb”：jdbc:mysql:replication://black,blue,green/clusterdb。一旦使用这种方式连接，Connector/J将会根据连接的ReadOnly属性将事务路由到合适的服务器（查询使用connection.getReadOnly( )，写操作使用connection.setReadOnly(bool)）。

图16 一主两从结构

由于复制是异步的，如果应用执行一个需要绝对最新值的只读操作，那么应该发送到主服务器而不是从服务器。这种情况下，Connector/J应用运行connection.setReadOnly(false)。

4.2、高可用性

在这种场景中，将更改从主服务器复制到从服务器的目的是当主服务器由于错误、崩溃或者维护而离线时切换到从服务器。

与横向扩展相同，可以采用各种方法选择正确的服务器，对于图17所示的使用Connector/J的配置（“black”是主服务器，“blue”是从服务器），应用可以使用连接串：jdbc:mysql://black,blue/clusterdb。当“black”可用时，Connector/J将所有操作发送到“black”；否则，切换到“blue”。

图17 主-从复制配置

4.3、地理复制

地理复制可以将数据在两个地理上分布的位置（通常距离很远）之间进行复制。由于存在潜在的网络延迟，异步复制是这种场景的首选方案。一个可能的示例是将New York的总公司的数据复制到San Francisco的分公司，以便能够针对本地数据存储执行查询。很明显，这也是一个在某一站点发生灾难时（例如断电或者自然灾害）提供灾难恢复的方法。

图18 地理冗余复制

4.4、备份数据库

为了避免复制可能导致的主服务器性能减退或者锁定，可以选择在从服务器上执行备份。注意，使用MySQL集群或者MySQL企业备份时，备份时可以继续执行InnoDB的读写。

4.5、分析

许多商业智能或者分析查询都是资源密集型的，需要大量的执行时间。对于这种用例，可以创建从服务器以服务这些分析查询。在这种配置中，主服务器不会受到这些查询的影响。

这种场景使用MySQL集群尤其有效，MySQL集群可以用于那些主要基于主键执行读写，同时可以允许更长时间执行针对大数据量的复杂查询的应用。只需要将MySQL集群数据复制到另一个存储引擎（通常是InnoDB），然后在那里生成报告。可以在执行这些操作的同时将数据复制到一个远程的MySQL集群站点，提供地理冗余，如图19所示。

图19 组合复制用例

5、复制拓扑

MySQL支持各种复制拓扑。下文讨论一些拓扑，包括某些有条件性支持的拓扑。

图20 常见的MySQL复制拓扑

5.1、一主一从复制

这是最流行的，易于配置和管理的拓扑结构。这种拓扑包含两个服务器，一个主服务器和一个从服务器。所有的写操作都在主服务器上执行，读操作在主服务器和从服务器之间分布。

5.2、一主多从复制

这种情况下，多个从服务器连接一个主服务器。这样能够更大程度地进行横向扩展，代价是需要更多的管理。

5.3、分层或级联复制

这种配置是一主一从或者一主多从的扩展。这种情况下，额外的从服务器连接到那些已经连接到根节点主服务器的从服务器。中间的从服务器同时作为主服务器和从服务器。在这种配置中，所有的写操作发送到根节点主服务器。

5.4、多主复制

在一个主/主配置中，两个服务器结合成一对，互相之间既为主服务器又是从服务器。虽然这种配置可以任意服务器上执行写操作，并最终被复制到另一服务器；但是它增加了安装、配置和管理的复杂度。另外，除非使用MySQL集群，无法进行冲突检测/解决。因此应用必须确保当一个服务器更新一行数据时，另一个服务器没有更新相同的行，并且该更新还没有被复制到前一个服务器上。

注意，任何时候一个从服务器只能拥有一个主服务器；如果需要模拟多主一从复制，用户需要定期切换到某个主服务器。

5.5、多主环形复制

还可以将多个MySQL服务器连成一个环形，提供更大程度的可扩展性和性能（假设应用能够避免将同一行的冲突更新发送到不同的服务器）。MySQL 5.5引入了一个新的过滤特性，能够更好地处理由于更新同时发送到多个服务器导致的失败。

图21 多主环形复制

当在多主环形复制中使用自增长的列时，应该使用auto_increment_offset和auto_increment_increment参数确保不会在多个服务器上产生重复的值。表1显示了一个3服务器的示例（black、blue和green）。

服务器 auto_increment_increment

auto_increment_offset

取值

black 3 1 1,4,7 ...

blue 3 2 2,5,8 ...

green 3 3 3,6,9 ...

表1 避免冲突的自增长值

5.6、多主一从复制

MySQL当前不支持这种复制拓扑。在多主配置中，一个从服务器本质上需要“侍奉二主”，意味着从服务器同时从多个主服务器接收变更。如果需要模拟多主一从复制，用户需要定期在多个主服务器之间切换。

MySQL集群允许多个服务器写入相同的集群。每个服务器都能作为自身主服务器的从服务器，因此可以为需要合适的应用配置这种功能。

6、复制内部工作流

MySQL复制通过以下方式实现：主服务器记录数据变更（DML：INSERT、UPDATE和DELETE）以及对象结构变更（DDL，例如ALTER TABLE等），然后立即或者一段时间间隔之后（使用延时复制时）将变更日志发送并应用到从服务器中。

图22描绘了MySQL复制的实现流程。

图22 MySQL复制工作流

通过MySQL复制，主服务器将更新写入它的二进制日志文件，并且为了记录日志循环维护一个日志文件的索引。二进制日志文件用作被发送到从服务器的更新的一个记录。当从服务器连接到它的主服务器后，判断它最后成功更新的日志位置。然后从服务器接收从该时间点之后发生的更新。随后从服务器阻塞并等待主服务器通知新的更新。

从MySQL 5.6开始，用户可以选择使用全局事务标识符（GTIDs），每个从服务器将会记录所有接收到的事务GTID。当从服务器连接时，它可以执行一个与主服务器的握手操作，确定需要复制的全部变更（更多细节参见第3节），因此不再需要知道二进制日志当前位置。

6.1、复制线程

MySQL使用了多个线程来实现从主服务器到从服务器的复制；如果使用了MySQL集群，还引入了一个额外的线程，详细信息参考第7节。

二进制日志转储线程

主服务器创建该线程，用于发送二进制日志内容到从服务器。拥有多个从服务器的主服务器为每个并发连接的从服务器创建一个转储线程，每个从服务器拥有自己的I/O线程和SQL线程。

从服务器I/O线程

当在从服务器上提交START SLAVE语句时，将会创建一个I/O线程，它连接到主服务器并请求主服务器发送二进制日志中的更新记录。从服务器I/O线程随后读取主服务器二进制转储线程发送的更新，并在本地将更新复制到从服务器的中继日志文件中。

从服务器SQL线程

从服务器创建该线程（调用START SLAVE时），用于读取从服务器I/O线程写入的中继日志，并执行其中的更新操作。如果使用了多线程从服务器，将会在从服务器上创建多个SQL线程。

6.2、复制日志文件

MySQL服务器在复制过程中创建了许多文件，用于保存来自主服务器的中继二进制日志和中继日志中的当前记录信息的状态和位置。

从服务器在复制过程中使用了以下三种类型的文件：

中继日志

从服务器上的中继日志包含了从主服务器二进制日志中读取的事件。这些事件最终由从服务器上的SQL线程执行。

master.info

从服务器的状态和当前配置信息存储在master.info文件中。该文件包含了从服务器的复制连接信息，包括主服务器的主机名称、使用的登录认证以及从服务器当前已经读取的主服务器二进制日志位置。如果参数master-info-repository设置为table，不需要使用该文件。

relay-log.info

关于从服务器中继日志中的执行点状态信息存储在relay-log.info文件中。如果参数relay-log-info-repository

设置为table，不需要使用该文件。

在主服务器上，存在二进制日志文件和相关的索引文件，用于追踪被复制所有更新。

7、MySQL集群复制的差异

MySQL集群是一个可扩展、实时性、遵循ACID原则的事务型开源数据库，可用性高达99.999%，总体拥有成本（TCO）低。MySQL集群围绕分布式、多主架构设计，无单一故障点。它可以在商业硬件的基础上横向扩展，具有透明的自动分片功能，主要用于读写密集型的工作负荷环境，可通过SQL和NoSQL接口访问。

MySQL集群可以作为MySQL的一个可插拔式存储引擎，但是它的架构与其他MySQL存储引擎（例如InnDO和MyISAM）从根本上是不同的，复制的实现和工作方式也不同。架构如图23所示。从复制的影响来说，关键的架构特性是数据没有存储在某个MySQL服务器实例中，而是分别在多个数据节点上。集群中的数据节点对之间通过同步复制提供高可用性。注意，这个同步复制与本文描述的复制无关。数据既可以从数据节点直接访问（例如使用本地C++ API），也可以使用一个或者多个MySQL服务器提供SQL访问。每台MySQL服务器都可以读写任何表中的行，并且修改对于其他服务器立即可见。

图23 MySQL集群架构

MySQL复制通常与MySQL集群一起使用以提供地理冗余。内部（同步）复制提供了集群中同地协作的数据节点之间的高可用性，而到远程站点的MySQL（异步）复制防止了灾难性的站点故障。

这将如何影响MySQL复制？变更可以在任何MySQL服务器上，甚至直接在数据节点上产生，而通过某种机制可以将变更集中到一个或者多个选定的MYSQL服务器（作为复制主服务器）的二进制日志中。这是通过NDB二进制日志注射线程执行的。该线程确保了所有的变更按照正确的顺序写入二进制日志。

如图24所示，这种机制提供了一个更加健壮的复制系统结构。两个服务器的二进制日志都包含了完全相同的变更，任何一个服务器都可以作为复制的主服务器。MySQL集群部署到一个使用InnoDB或者MyISAM存储引擎的MySQL服务器上。

图24 多主服务器集群

虽然每个主服务器的二进制日志包含相同的变更，它们之间是相互独立的。为了实现从服务器从一个主服务器到另一个主服务器的故障转移，集群范围的“纪元”用于代表集群在某一时间点的状态。更多高级故障转移技术可以查看MySQL集群参考指南http://dev.mysql.com/doc/refman/5.5/en/mysql-clusterreplication-failover.html。

MySQL集群支持多主服务器主主配置下的复制，甚至环形复制。另外，MySQL集群能够提供冲突检测或者解决不同主服务器写入相同行的冲突变更。更多细节可以查看MySQL集群参考指南。

MySQL集群版本与MySQL主版本的发布计划不同，因此最新的复制特性在最新的集群本版中不总是可用的。例如，编写最新的MySQL集群 7.2通用版本时，使用的是MySQL 5.5修改版，因此没有包含MySQL 5.6中引入的增强特性。

当使用MySQL集群复制时，总是使用基于行的复制（而不是基于语句的复制）。

8、使用MySQL企业监控器监控复制

MySQL企业监控器与查询分析器是一个分布式Web应用程序，可以在内部或者云端部署。监控器持续健康所有的MySQL服务器，并前摄式警告潜在的问题，在它们成为高代价的故障之前提供调整的机会。它还为已经发现的问题提供专家意见，让你知道如何优化系统。

图25 MySQL企业监控器

MySQL企业监控器使用复制监控器，提供各种主从层次关系的自动检测、分组、记录和监控，使得更容易进行横向扩展和获得高可用性。现有复制拓扑的改变和添加同样能够自动检测和显示，为DBA提供最新改变的即时可见性。

使用复制监控器和复制顾问中的专家建议可以检查当前主从状态，并查看与诊断和纠正问题相关的度量（例如从服务器I/O线程、从服务器SQL线程、滞后主服务器的秒数、最后错误等等）。

复制监控器的设计和实现是用于节省编写和维护收集、整合与监控相似的MySQL复制状态和诊断数据的DevOps时间。

MySQL企业监控器还存储了历史的MySQL状态数据，因此极大地简化了问题分析。

复制顾问能够标识问题并发生告警，DBA能够使用复制监控器和告警信息深入了解受影响的主服务器和/或从服务器的状态。

图26 MySQL企业监控器的复制统计