概述

复制允许将来自一个MySQL数据库服务器(主服务器)的数据复制到一个或多个MySQL数据库服务器(从服务器)。 默认情况下，复制是异步的 从站不需要永久连接以接收来自主站的更新。 根据配置，您可以复制数据库中的所有数据库，所选数据库甚至选定的表。

复制的好处包括：

1、 横向扩展解决方案

在多个从站之间分配负载以提高性能。 在此环境中，所有写入和更新都必须在主服务器上进行。 但是，读取可能发生在一个或多个从站上。 该模型可以提高写入性能(因为主设备专用于更新)，同时显着提高了越来越多的从设备的读取速度

2、数据安全

因为数据被复制到从站，并且从站可以暂停复制过程，所以可以在从站上运行备份服务而不会破坏相应的主数据。

3、分析

可以在主服务器上创建实时数据，而信息的分析可以在从服务器上进行，而不会影响主服务器的性能。

4、远程数据分发

您可以使用复制为远程站点创建数据的本地副本，而无需永久访问主服务器。

MySQL 8.0支持不同的复制方法。 传统方法基于从主机的二进制日志复制事件，并要求其中的日志文件和位置在主机和从机之间同步。 基于全局事务标识符(GTID)的较新方法是事务性的，因此不需要处理这些文件中的日志文件或位置，这极大地简化了许多常见的复制任务。 只要在主服务器上提交的所有事务也已应用于从服务器，使用GTID进行复制可确保主服务器和从服务器之间的一致性。 有关MySQL中基于GTID和GTID的复制的更多信息，请参见第17.1.3节“使用全局事务标识符进行复制”。 有关使用基于二进制日志文件位置的复制的信息，请参见第17.1节“配置复制”。

MySQL中的复制支持不同类型的同步。原始类型的同步是单向异步复制，其中一个服务器充当主服务器，而一个或多个其他服务器充当从服务器。这与作为NDB Cluster特征的同步复制形成对比(参见第22章，MySQL NDB Cluster 8.0)。在MySQL 8.0中，除了内置的异步复制之外，还支持半同步复制。使用半同步复制，在返回执行事务的会话之前对主块执行提交，直到至少一个从服务器确认已接收并记录事务的事件为止;请参见第17.3.11节“半同步复制”。 MySQL 8.0还支持延迟复制，使得从属服务器故意滞后于主服务器至少一段指定的时间;请参见第17.3.12节“延迟复制”。对于需要同步复制的方案，请使用NDB Cluster(请参阅第22章，MySQL NDB Cluster 8.0)。

有许多解决方案可用于在服务器之间设置复制，最佳使用方法取决于您使用的数据和引擎类型的存在。 有关可用选项的更多信息，请参见第17.1.2节“设置基于二进制日志文件位置的复制”。

这里有两种核心类型的复制格式：基于语句的复制(SBR)，它复制整个SQL语句，以及基于行的复制(RBR)，它只复制已更改的行。 您还可以使用第三种混合复制(MBR)。 有关不同复制格式的更多信息，请参见第17.2.1节“复制格式”。

通过许多不同的选项和变量来控制复制。 有关更多信息，请参见第17.1.6节“复制和二进制日志记录选项和变量”。

您可以使用复制来解决许多不同的问题，包括性能，支持不同数据库的备份，以及作为缓解系统故障的更大解决方案的一部分。 有关如何解决这些问题的信息，请参见第17.3节“复制解决方案”。

有关如何在复制期间处理不同数据类型和语句的说明和提示，包括复制功能，版本兼容性，升级和潜在问题及其解决方案的详细信息，请参见第17.4节“复制说明和提示”。 有关MySQL Replication新手经常提出的一些问题的答案，请参见第A.13节“MySQL 8.0 FAQ：复制”。

有关复制实现，复制如何工作，二进制日志的过程和内容，后台线程以及用于决定如何记录和复制语句的规则的详细信息，请参见第17.2节“复制实现”。

复制解决方案

一、 备份

要将复制用作备份解决方案，请将数据从主服务器复制到从服务器，然后备份数据从服务器。 从站可以暂停和关闭，而不会影响主站的运行操作，因此您可以生成“实时”数据的有效快照，否则需要关闭主站。

备份数据库的方式取决于其大小以及是仅备份数据，还是备份数据和复制从属状态，以便在发生故障时重建从站。 因此有两种选择：

1、如果您使用复制作为解决方案来使您能够备份主服务器上的数据，并且数据库的大小不是太大，则mysqldump工具可能是合适的。 请参见第17.3.1.1节“使用mysqldump备份从站”。

2、对于较大的数据库，其中mysqldump不切实际或效率低下，您可以备份原始数据文件。 使用原始数据文件选项还意味着您可以备份二进制文件和中继日志，以便在从站发生故障时重新创建从站。 有关更多信息，请参见第17.3.1.2节“从从站备份原始数据”。

3、另一种可用于主服务器或从服务器的备份策略是将服务器置于只读状态。 对只读服务器执行备份，然后将其更改回其通常的读/写操作状态。 请参见第17.3.1.3节“通过将其设置为只读来备份主设备或从设备”。

二、处理复制从属的意外停止

三、监控基于行的复制

四、使用具有不同主存储引擎和从存储引擎的复制

五、使用复制进行横向扩展

六、将不同的数据库复制到不同的从属服务器

七、提高复制性能

八、故障转移期间切换主站

九、设置复制以使用加密连接

十、加密二进制日志文件和中继日志文件

十一、半同步复制

十二、延迟复制

复制的实现

复制时基于master在binary log中跟踪记录从服务器启动后对数据库的结构和内容做的所有变更。

连接到master的slave 请求binary log的拷贝，也就是从master拉取数据，而不是master推送数据到slave。slave执行收到的binary log中的事件，这有重复原始变更的效果，就像在master上进行的一样。创建表或修改其结构，插入，删除和更新数据，就像在master服务器上执行过的一样。

一、复制格式

复制机制工作原理是在master上执行过的事件记录在binarylog中，并在slave上也重复执行。根据事件类型不同，以不同的形式记录在bin log中，不同的复制格式和master中事件记录在bin log的形式相符。复制格式和相关术语关联如下：

1、使用基于语句的二进制日志记录时，主服务器会将SQL语句写入二进制日志。 通过在从站上执行SQL语句，将主站复制到从站。 这称为基于语句的复制(可以缩写为SBR)，它对应于基于MySQL语句的二进制日志记录格式。

优点： a、成熟的技术 ；

b、写入日志文件的数据较少。 当更新或删除影响许多行时，这会导致日志文件所需的存储空间大大减少。 这也意味着可以更快地完成从备份中获取和恢复；

c、日志文件包含进行任何更改的所有语句，因此可用于审计数据库。

缺点：

a、不安全的语句。非确定性的语句很难复制

b、INSERT ... SELECT需要比基于行的复制更多的行级锁。

c、UPDATE需要进行表扫描(因为WHERE子句中没有使用索引)必须锁定比基于行的复制更多的行。

d、对于InnoDB：使用AUTO_INCREMENT阻止其他不冲突的INSERT语句的INSERT语句。

e、对于复杂语句，必须在更新或插入行之前在从属服务器上评估和执行该语句。 对于基于行的复制，从属服务器只需修改受影响的行，而不是执行完整语句。

。。。。。。

2、使用基于行的日志记录时，主服务器会将事件写入二进制日志，以指示各个表行的更改方式。 通过将表示表行更改的事件复制到从站，可以将主服务器复制到从服务器。 这称为基于行的复制(可以缩写为RBR)。

默认是基于行的复制。

优点：a、所有的变更都可以复制，最安全的复制格式

b、对于以下类型的语句，主服务器上需要更少的行锁，从而实现更高的并发性：AUTO_INCREMENT

WHERE clauses that do not use keys or do not change most of the examined rows.

c、对于任何INSERT，UPDATE或DELETE语句，从站上都需要更少的行锁。

缺点：

a、RBR生成更多必须记录的日志数据。

b、生成大型BLOB值的确定性UDF使用基于行的复制比使用基于语句的复制需要更长的时间来复制。 这是因为记录了BLOB列值，而不是生成数据的语句。

c、您无法在从站上看到从主站接收和执行的语句。 但是，您可以使用带有选项--base64-output = DECODE-ROWS和--verbose的mysqlbinlog查看更改了哪些数据。

d、对于使用MyISAM存储引擎的表，当将INSERT语句作为基于行的事件应用于二进制日志而不是将它们作为语句应用时，INSERT语句的从属服务器需要更强的锁定。 这意味着在使用基于行的复制时，不支持在MyISAM表上进行并发插入。

3、您还可以将MySQL配置为使用基于语句和基于行的日志记录的混合，具体取决于哪个最适合要记录的更改。 这称为混合格式日志记录。 使用混合格式日志记录时，默认情况下使用基于语句的日志。 根据某些语句以及正在使用的存储引擎，在特定情况下，日志会自动切换到基于行的语句。

二、复制实现细节

MySQL复制功能使用三个线程实现，一个在主服务器上，两个在从服务器上：Binlog dump thread.

当slave来链接master时，master会创建一个线程，以便发送bin-log的内容。 可以在主服务器上的SHOW PROCESSLIST的输出中将此线程标识为Binlog转储线程。

Binlog dump thread.获取master 的bin-log的锁，用于读取要发送到slave的每个事件。 一旦读取了事件，即使在事件发送到从站之前，锁也会被释放。Slave I/O thread.

在slave发布Slave I/O thread读取记录并复制本地文件中，这就构成了中继日志。Slave SQL thread.

slave创建一个SQL线程来读取由io线程写入的中继日志，并执行其中包含的事件。

三、复制通道

复制通道表示从主站到从站的事务路径。

为了提供与先前版本的兼容性，MySQL服务器在启动时自动创建一个默认通道，其名称为空字符串(“”)。 这个频道总是存在; 它不能被用户创建或销毁。 如果没有创建其他通道(具有非空名称)，则复制语句仅作用于缺省通道，以便旧版slave的所有复制语句按预期运行

复制通道包含从主设备传输到从设备的事务路径。 在多源复制中，从站打开多个通道，每个通道一个，每个通道都有自己的中继日志和应用程序(SQL)线程。 一旦复制通道的接收器(I / O)线程接收到事务，它们就会被添加到通道的中继日志文件中并传递给应用程序线程。 这使通道能够独立运行。

四、复制中继和状态日志

复制过程创建多个日志保存中继日志和当前的状态，有：

a、relay log 包含bin-log记录

b、master info log包含slave与master连接的状态和当前配置信息。 此日志包含有关master的主机名，登录凭据和坐标的信息，这些坐标指示slave从master的bin-log中读取了多远。 e master info log i将写入mysql.slave_master_info表。

c、relay log info log 保存有关slave的relay log的执行点的状态信息。 relay log写入mysql.slave_relay_log_info表。

使复制适应意外停止

mysql.slave_master_info和mysql.slave_relay_log_info表是使用事务存储引擎InnoDB创建的。 slave_relay_log_info表的更新与事务一起提交，这意味着记录在该日志中的从属进度信息始终与应用于数据库的内容一致，即使服务器意外停止也是如此。 必须在从站上启用--relay-log-recovery选项以保证弹性。

五、服务器如何评估复制过滤规则

master

slave replicate-* 配置哪些复制，CHANGE REPLICATION FILTER 同样动态调整