MySQL 5.7 复制原理简介

MySQL 复制介绍

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

MySQL中复制的优点包括：

• 横向扩展解决方案 - 将负载分散到多个从服务器以提高性能。 在此环境中，所有写入和更新都必须在主服务器上进行。 然而，读可能发生在一个或多个从服务器身上。 这种模式可以提高写入的性能（因为主服务器专用于更新），同时显着提高越来越多的从服务器的读取速度。
• 数据安全性 - 因为数据被复制到从服务器，从服务器可以暂停复制过程，所以可以在从服务器上运行备份服务，而不会破坏相应的主服务数据。
• 分析 - 可以在主服务器上创建实时数据，而信息的分析可以在从服务器上进行，而不会影响主服务器的性能。
• 远程数据分发 - 您可以使用复制为远程服务器创建本地数据副本，而无需永久访问主服务器数据。

MySQL 5.7支持不同的复制方法。 传统的方法是基于主服务器的二进制日志事件，并要求主服务器和从服务器的日志文件和日志文件中同步的位置。 基于全局事务标识符（GTIDs）的新方法是事务性的，因此并不需要日志的文件或日志中同步的位置，从而大大简化了许多常见的复制任务工作。 只要在主服务器上提交的所有事务也被应用在从站上，使用GTIDs的复制就可以保证主服务器和从服务器之间的一致性。（注：本文只讲解基于binlog方式的复制原理，关于GTIDs后期有时间再补充。）

MySQL 复制解决的问题

• 数据分布（data distribution）
• 负载平衡（load balancing）
• 备份（backup）
• 高可用性和容错行（high availability and failover）

MySQL 支持的复制类型

• 基于语句的复制。 在主服务器上执行的 SQL 语句，在从服务器上执行同样的语句。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对服务器上的表所进行的更新之间的冲突，配置：binlog_format = ‘STATEMENT’
• 基于行的复制。把改变的内容复制过去，而不是把命令在从服务器上执行一遍，从 MySQL 5.0开始支持，配置：binlog_format = ‘ROW’
• 混合类型的复制。默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制,配置：binlog_format = ‘MIXED’

MySQL 复制是如何工作的（binlog方式）？

从高层来看，复制分成三步：
- master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）
- slave将master的binary log events拷贝到它的中继日志(relay log)
- slave重做中继日志中的事件，将改变反映它自己的数据

该过程的第一部分就是master记录二进制日志。在每个事务更新数据完成之前，master在二日志记录这些改变。MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，master通知存储引擎提交事务。

下一步就是slave将master的binary log拷贝到它自己的中继日志。首先，slave开始一个工作线程——I/O线程。I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果已经跟上master，它会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。

SQL slave thread处理该过程的最后一步。SQL线程从中继日志读取事件，更新slave的数据，使其与master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。
此外，在master中也有一个工作线程：和其它MySQL的连接一样，slave在master中打开一个连接也会使得master开始一个线程。复制过程有一个很重要的限制——复制在slave上是串行化的，也就是说master上的并行更新操作不能在slave上并行操作。

具体实践可以参考我之前的一篇文章：以Docker方式实现MySql 主从复制（实践篇）

作者：crane-yuan 日期：2017-11-30

参考文章

• MySQL 5.7 Reference Manual :: Chapter 16 Replication
• 理解MySQL——复制(Replication)