MySQL数据库集群实战———MySQL主从复制之异步模式（基于position、基于GTID）

一、Mysql的主从复制

1、为什么要做主从复制？

在业务复杂的系统中，有这么一个情景，有一句sql语句需要锁表，导致暂时不能使用读的服务，那么就很影响运行中的业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

2、mysql主从复制的原理

当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。

主从复制的基础是主库记录数据库的所有变更记录到binlog（ binary log，主库中保存更新事件日志的二进制文件）。binlog是数据库中保存配置中过期时间内所有修改数据库结构或内容的一个文件。如果过期时间是10d的话，那么就是最近10d的数据库修改记录。
mysql主从复制是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。

• 在 主库 里，只要有更新事件出现，就会被依次地写入到binlog里面，是之后从库连接到主库时，从主库拉取过来进行复制操作的数据源。
  binlog输出线程 每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。 对于每一个即将发送给从库的sql事件，binlog输出线程会将其锁住。一旦该事件被线程读取完之后，该锁会被释放，即使在该事件完全发送到从库的时候，该锁也会被释放。

• 在 从库 里，当复制开始的时候，从库就会创建两个线程进行处理：

  从库I/O线程 当START SLAVE语句在从库开始执行之后，从库启动I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。
  从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。

  从库的SQL线程 从库启动SQL线程，这个线程读取从库I/O线程写到relay log（中继日志）的更新事件并执行。

可知道，对于每一个主从复制的连接，都有三个线程。拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程，每一个从库都有它自己的I/O线程和SQL线程。 从库通过启动两个独立的线程，使得在进行复制时，从库的读和写进行了分离。因此，即使负责执行的线程运行较慢，负责读取更新语句的线程并不会因此变得缓慢。比如说，如果从库有一段时间没运行了，当它在此启动的时候，尽管它的SQL线程执行比较慢，它的I/O线程可以快速地从主库里读取所有的binlog内容。这样一来，即使从库在SQL线程执行完所有读取到的语句前停止运行了，I/O线程也至少完全读取了所有的内容，并将其安全地备份在从库本地的relay log，随时准备在从库下一次启动的时候执行语句。

3、异步复制

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主库如果crash掉了，此时主库上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主库上的数据不完整。

二、基于position的异步复制

实验环境

实验环境

主机名 IP	服务
虚拟机server1 172.25.7.1	数据库的master节点
虚拟机server2 172.25.7.2	数据库的slave节点
物理机 172.25.7.250	测试端

1、在server1和server2上，下载mysql的rpm包，解压：
tar xf mysql-5.7.24-1.el7.x86_64.rpm-bundle.tar


2、安装需要的包

yum install -y mysql-community-client-5.7.24-1.el7.x86_64.rpm mysql-community-common-5.7.24-1.el7.x86_64.rpm mysql-community-libs-5.7.24-1.el7.x86_64.rpm mysql-community-libs-compat-5.7.24-1.el7.x86_64.rpm mysql-community-server-5.7.24-1.el7.x86_64.rpm

server2上同样的操作：

3、修改配置文件，开始配置主节点（server1）数据库 vim /etc/my.cnf

在文件末尾写：
log