MySQL 主从复制

1、复制概述

MySQL的复制原理大致如下：

（1）首先，MySQL主库在事务提交时会把数据变更作为事件Events记录在二进制日志文件Binlog中；MySQL主库上的sync_binlog参数控制Binlog日志刷新到磁盘。

（2）主库推送二进制日志文件Binlog中的事件到从库的中继日志Relay Log，之后从库根据中继日志Relay Log重做数据变更操作，通过逻辑复制以此来达到主库和从库的数据一致。

MySQL通过3个线程来完成主从库间的数据复制：其中Binlog Dump线程跑在主库上，I/O线程和SQL线程跑在从库上。当在从库上启动复制（START SLAVE）时，首先创建I/O线程连接主库，主库随后创建Binlog Dump线程读取数据库事件并发送给I/O线程，I/O线程获取到事件数据后更新到从库的中继日志Relay Log中去，之后从库上的SQL线程读取中继日志Relay Log中更新的数据库事件并应用，如下图所示：

注：MySQL的复制是异步的，从库上的数据和主库存在一定的延迟。Binlog文件支持Statement、Row、Mixed三种格式，也对应了MySQL的三种复制技术。

2、复制的3种常见架构

复制的3种常见架构有一主多从复制架构、多级复制架构和双主复制架构。

2.1、一主多从复制架构

在主库读取请求压力非常大的场景下，可以通过配置一主多从复制架构实现读写分离，把大量对实时性要求不是特别高的读请求通过负载均衡分布到多个从库上，降低主库的读取压力，如下图所示：

2.2、多级复制架构

一主多从的架构能够解决大部分读请求压力特别大的场景的需求，考虑到MySQL的复制是主库“推送”Binlog日志到从库，主库的I/O压力和网络压力会随着从库的增加而增长（每个从库都会在主库上有一个独立的Binlog Dump线程来发送事件）、而多级复制架构解决了一主多从场景下，主库额外的I/O和网络压力。如下图所示：

2.3、双主复制架构

双主复制架构特别适用于DBA做维护等需要主从切换的场景，通过双主复制架构避免了重复搭建从库的麻烦。如下图所示：

主库Master1和Master2互为主从，所有Web Client客户端的写请求都访问主库Master1，而读请求可以选择访问主库Master1或Master2。

2、复制搭建过程

2.1、异步复制

MySQL的主从复制至少需要两个MySQL服务，这些MySQL服务可以分布在不同的服务器上，也可以在一台服务器上启动多个服务。主从复制配置的步骤比较简单，下面进行详细介绍。

（1）确保主从库上安装了相同版本的数据库。因为复制的功能在持续的改进中，索引在可能的情况下推荐安装最新的稳定版本。

（2）在主库上，设置一个复制使用的账户，并授予REPLICATION SLAVE权限。这里创建一个复制用户rep1，可以从IP为192.168.7.200的主机进行连接：

（3）修改主数据库服务器的配置文件my.cnf，开启BINLOG，并设置server-id的值。这两个参数的修改需要重新启动数据库服务才可以生效。

在my.cnf中修改如下：

（4）在主库上，设置读锁定有效，这个操作是为了确保没有数据库操作，以便获得一个一致性的快照：

（5）然后得到主库上当前的二进制日志名和偏移量值。这个操作的目的是为了在从数据库启动以后，从这个点开始进行数据的恢复。

（6）现在主数据库服务器已经停止了更新操作，需要生成主数据库的备份，备份的方式有很多种，可以直接在操作系统下复制全部的数据文件到从数据库服务器上，也可以通过mysqldump导出数据或者使用ibbackup工具进行数据的备份。如果主数据库的服务可以停止，那么直接复制数据文件应该是最快的生成快照的方法：

（7）主数据库的备份完毕，可以恢复写操作，剩下的操作只需要在从库上执行：

（8）将主数据库的一致性备份恢复到从数据库上。如果是使用.tar打包的文件包，只需要解开到相应的目录即可。

（9）修改从数据库的配置文件my.cnf，增加server-id参数。注意server-id的值必须是唯一的，不能和主数据库的配置相同，如果有多个从数据库服务器，每个送数据库服务器必须有自己唯一的server-id值。

在my.cnf中修改如下：

（10）在从库上，使用--skip-slave-start选项启动从数据库，这样不会立即启动从数据库服务上的复制进程，方便我们对从数据库的服务进行进一步的配置：

（11）对从数据库服务器做相应设置，指定复制使用的用户，主数据库服务器的IP、端口以及开始执行复制的日志文件和位置等，具体代码如下：

（12）在从库上，启动slave线程：

（13）这时slave上执行show processlist命令查看是否已连接上master。

2.2、半同步复制

在MySQL 5.5之前，MySQL的复制是异步操作，主库和从库的数据之间存在一定的延迟，这样存在一个隐患：当在主库上写入一个事务并提交成功，而从库尚未得到主库推送的Binlog日志时，主库宕机了，例如主库可能因磁盘损坏、内存故障等造成主库上该事务Binlog丢失，此时从库就可能损失这个事务，从而造成主从不一致。

为了解决这个问题，MySQL 5.5引入了半同步复制机制。在MySQL 5.5之前的异步复制时，主库执行完Commit提交操作后，在主库写入Binlog日志后即可成功返回客户端，无需等待Binlog日志传送给从库，如下图所示：

而半同步复制时，为了保证主库上的每一个Binlog事务能够被可靠的复制到从库上，主库在每次事务成功提交上时，并不及时反馈给前段应用用户，而是等待其中一个从库也接收到Binlog事务并成功写入中继日志后，主库才返回Commit操作成功给客户端。半同步复制保证了事务成功提交后，至少有两份日志记录，一份在主库的Binlog日志上，另一份在至少一个从库的中继日志Relay Log上，从而更进一步保证了数据的完整性。半同步复制的大致流程如下图所示：

半同步复制模式下，假如在上图的步骤1、2、3中的任何一个步骤中主库宕机，则事务并未提交成功，从库中也没有收到事务对应的Binlog日志，所以主从数据是一致的；假如在步骤4传递Binlog日志到从库时，从库宕机或者网络故障，导致Binlog并没有及时地传递到从库上，此时主库上的事务会等待一段时间，如果Binlog在这段时间内都无法成功推送到从库上，则MySQL自动调整复制为异步模式，事务正常返回提交结果给客户端。

半同步复制很大程度上取决于主从库之间的网络情况，往返时延RTT越小决定了从库的实时性越好。通俗地说，主从库之间网络越快，从库越实时。

半同步模式是作为MySQL 5.5的一个插件来实现的，主库和从库使用不同的插件。安装比较简单，在异步复制的环境上，安装半同步复制插件即可。

（1）首先，判断MySQL服务器是否支持动态增加插件：

（2）确认支持动态增加插件后，检查MySQL的安装目录下是否存在插件，一般默认在$MYSAL_HOME/lib/plugin目录下存在主库插件semisync_master.so和从库插件semisync_slace.so：

在主库上安装插件semisync_master.so插件：

从库上则安装semisync_slave.so插件：

安装完成后，从plugin表中能够看到刚才安装的插件：

也就是说，安装完成后，MySQL会在系统表plugin中记录刚才安装的插件，下次系统重启后会自动加载插件。

（3）需要分别在主库和从库上配置参数打开半同步semi-sync，默认半同步设置是不打开的，主库上配置全局参数：

从库上一样配置全局参数：

注意，由于之前配置的复制是异步复制，所以需要重启一下从库上的I/O线程（如果是全新配置的半同步复制则不需要）：

至此半同步配置完毕。