2.1 主从复制

主从复制是MySQL的经典功能，也是应用最广泛的功能。主从复制是指将来自一台MySQL数据库服务器（主服务器）的数据，复制到一台或多台MySQL数据库服务器（从服务器）。默认情况下，复制采用异步方式，MySQL还提供半同步复制和增强半同步复制。复制配置成功后，从服务器无须与主服务器一直保持连接，只要从服务器连接到主服务器即可从主服务器接收更新。根据配置的不同，用户可以复制数据库中的全部数据库（模式）或者是选定的数据库（模式），甚至是选定的表。图2-2是MySQL主从复制的示意图。

2.1.1 主从复制的优点

MySQL的主从复制能够被用户广泛地使用，得益于以下优点。

● 横向扩展解决方案 ：在多个从服务器之间分散工作负载以提高性能。所有写入和更新都必须在主服务器上进行，但读取可能发生在一个或多个从服务器上。该方案可以提高写入性能（因为主服务器专用于更新），并且伴随着从服务器的增加，可以显著提高读取速度。

● 数据安全性 ：从服务器可以暂停复制过程，因此，用户可以在从服务器上运行备份，而不会破坏相应的源数据。

● 分析 ：用户可以在主服务器上创建实时数据，数据分析可以在从服务器上进行，它不会影响主服务器的性能。

● 远程数据分发 ：用户可以使用复制来创建数据的本地副本，以供远程站点使用，远程站点无须持续访问主服务器。

● 延迟复制 ：MySQL支持延迟复制，从服务器可以延迟执行从主服务器接收的事务。该功能有助于在主服务器出现误操作的情况下进行快速回退。

2.1.2 主从复制的缺点

主从复制功能推出的时间较长，渐渐地已经无法满足现代化的系统运维要求，其具有下列缺点。

● 手动配置 ：主从复制需要通过多个步骤进行手动配置，包括用户管理、备份恢复、复制配置等。在配置复制的过程中，需要用户配置用于复制的专用账户，并且需要备份主服务器的数据，将其恢复到从服务器，以及配置复制相关的选项等工作。

● 仅提供数据库层的核心功能 ：整体架构需要由用户决定，大部分情况下需要定制。复制仅仅在数据库层面实现了核心功能，在服务器的切换方式、与应用程序的配合等方面没有提供一套完整的方案，需要用户根据自身的需求选择其他产品来配合使用。

● 需要使用不同的技术组件 ：技术专家或DBA需要大量的工作和时间（专注自动化处理）。通常用户需要根据系统的实际情况，耗费大量的时间和人力成本进行开发和维护，比如应用程序的透明化故障转移等。

2.1.3 主从复制的方法概述

MySQL支持不同的复制方法。传统方法基于主服务器的二进制日志中的事件，主服务器和从服务器之间在进行数据同步时，要求使用日志文件及日志中的位置。新的方法基于GTID（Global Transaction ID，全局事务标识符）实现，该方法具有事务性，不需要使用日志文件和文件中的位置，从而大大简化了许多常见的复制任务（关于GTID的详细内容，将在3.2.2节阐述）。在使用GTID进行复制时，想要确保主服务器和从服务器之间的一致性，只需将主服务器上提交的所有事务全部应用到从服务器上即可。复制使用的日志格式主要有两种，基于语句格式的复制（SBR）和基于行格式的复制（RBR）。基于语句格式的日志，能够复制完整的SQL语句，基于行格式的日志仅复制更改的数据行。用户还可以使用混合复制（MBR），混合复制就是将上述两种格式进行混合使用。

2.1.4 主从复制的类型概述

主从复制支持不同类型的同步方式。默认的同步方式是MySQL内置的异步复制，由一台服务器作为主服务器，其他一台或多台服务器作为从服务器。除了内置的异步复制，MySQL还支持半同步复制。半同步复制与异步复制的区别在于事务在主服务器上提交的时间点不同。半同步复制在返回执行事务的会话之前，需要至少在一台从服务器上确认它已接收并记录了事务，才能够在主服务器上执行提交。此外，MySQL还支持延迟复制，从服务器可以指定时长，在指定时长之后，再从主服务器接收数据更新。

用户可以使用MySQL的主从复制解决包括性能问题在内的许多问题、支持不同数据库的备份，并可以减轻在大型解决方案中由系统故障带来的影响。

2.1.5 主从复制适用的高可用要求

通常情况下，系统的高可用性使用两个目标值进行衡量，即RTO（Recovery Time Objective）和RPO（Recovery Point Objective）。RTO为恢复时间目标，在灾难发生后，从IT系统宕机导致业务停止时开始，到IT系统恢复至可以支持各部门运作、恢复运营之时结束，此两点之间的时间段称为RTO。RPO为恢复点目标，对系统和应用数据而言，RPO是能够将业务恢复运行所需的对应时间点的数据。

基于高可用要求，如果RTO等于数分钟，RPO小于1秒，则可以选择异步复制配合手动应用切换的高可用方案，如图2-3所示。