第一节：MySQL主从复制概念及架构

背景

在了解主从复制之前必须要了解的就是数据库的二进制日志(binlog),主从复制架构大多基于二进制日志进行。

一、MySQL主从复制介绍

1.1、主从复制实现基本原理：

(1)、自带功能，复制是 MySQL 的一项功能，允许服务器将更改从一个实例复制到另一个实例。

(2)、主服务器将所有数据和结构更改记录到二进制日志中。

(3)、从服务器从主服务器请求该二进制日志并在本地应用其内容。

1.2 复制架构的应用常见场景：

(1)：主从服务器实现读写分离，从服务器实现负载均衡。

1.2 主–从复制

传统的 MySQL 复制提供了一种简单的主–从复制方法。 有一个主，以及一个或多个从。 主节点执行提交事务，然后将它们（异步地）发送到从节点，以重新执行。

还有一个半同步复制，它在协议中添加了一个同步步骤。 这意味着主节点在提交时需要等待至少一个从节点确认它已经接收到事务。只有这样，主节点才能继续提交操作。MySQL在5.5版本之前是不支持半同步的，在5.5版本的时候，Google为MySQL贡献了一个半同步的补丁以后，MySQL才支持半同步的。

　在上面的两个图片中，可以看到传统异步 MySQL 复制协议（以及半同步）的图形展示。 蓝色箭头表示在不同 server 之间或者 server 与 client 应用之间的信息交互。

1.3 MySQL主从复制——从库支不支持写操作
对于所有的从数据库而言，所有的数据都是从主数据复制而来的。

(1)、那请问，从数据库上能不能执行写操作？对于从数据库本身而言，是可以执行写操作的。但是如果你在从数据库上执行了写操作，但是这些操作不能被主数据库同步过去，这样就导致了主从数据库的不一致，所以我们应该禁止在从数据库上执行写操作。

(2)、从数据库不能执行写操作，那我们要从数据库干嘛呢？我们有以下用处：

在从数据库上做备份，将从数据库从生产环境下线，做备份。在备份的时候，我们要记录下来，那备份的那一刻开始，它所处的正在从主数据库上复制的那个二进制日志文件是什么，以及处在二进制日志文件中的位置。通过在从数据库上执行 show slave status 可以查看。

1.4 MySQL主从复制——从库要不要记录binlog

(1)、如果要的话，每一次写操作，都会记录二进制日志。并且记录的和主库上面的二进制日志是一样的，如果非要记录的话，但是又没有什么额外的作用，这样反而会拖慢从数据库的效率。出于这个目的，我们是不要记录二进制日志的。

(2)、如果是多级复制的话，那么既作为从数据库和主数据库的那台服务器是既需要二进制日志和中继日志的。如下图所示：

中间的两台从数据库是既需要中继日志和二进制日志的，否则最底层的从数据库没有办法实现主从复制。

1.5 MySQL主从复制——读写分离
如果主库上面连接的从库很多，那么当主库产生二进制日志的时候，需要分别将二进制日志发送给所有的从数据库，这就导致，如果从数据库越来越多的话，主数据库的负载就会越来越严重。例如如果有三个从数据库，那么主数据库就会启动三个线程，分别读取二进制日志，然后分别发送给三个从数据库。这里会存在大量的IO，那么如何规避这种情况呢？

1.4 MySQL主从复制——主库已有数据的解决方案
由单机架构切换到一主一从或一主多从，在增加从库节点前，主库可能已经运行过一段时间，这种情况在实际业务中很常
见。那么如何应对开启主从复制前主库有数据的场景呢？
解决方案：
先对主库的数据进行备份，然后将主数据库中导出的数据导入到从数据库，然后再开启主从复制，以此来保证主从数据库数据一致。

二、MySQL主从复制架构