概要MySQL主从复制概念MySQL主从复制主要用途MySQL主从复制形式MySQL主从复制原理MySQL主从复制模式总结概要

从MySQL3.23版本开始，MySQL支持主从复制功能，MySQL复制是通过将记录DDL和DML操作的日志文件（binlog）从主服务器传输到从服务器，从服务器重做日志，使从服务器与主服务器中的数据达到一致的状态。

主从复制的优点

1、如果主服务器出现问题，可以快速切换到从服务器2、可以在从服务器中执行查询操作，降低主服务器的压力3、可以在从服务器中进行备份，避免在备份期间影响主服务器的运行

MySQL主从复制解决的问题

1、数据分布2、负载均衡3、数据备份，安全4、高可用性和容错性5、读写分离，缓解数据库压力

注意：MySQL主从复制采用异步复制的方法，由于网络延迟的缘故，在从库中查询数据的时候要考虑到这些数据的不一致性差异，一般只有更新不频繁和对实时性不高的数据才通过从库查询数据。

MySQL 主从复制概念

MySQL主从复制指的是数据库数据可以从一个MySQL数据库主节点复制到一个或多个数据库从节点。MySQL默认采用异步复制的方式，这样从数据库不用一直访问主数据库，数据更新可以在远程服务器上进行，从数据库可以复制主数据库中所有的库，或者指定的数据库，或者特点的表。

MySQL主从复制的主要用途

读写分离

执行一条SQL语句的时候，会对相应的数据加锁，导致其他客户端阻塞等待而无法读取相应的数据，这样势必影响MySQL数据的性能，这样也就会影响现有业务，通过读写分离，主库负责写，从库负责读，即使主库出现锁表的情况，通过读从库也能保证业务的正常进行。

数据实时备份，当系统某个节点出现故障时，可以方便的故障切换（主从切换）

提高数据安全性，因为数据已经备份到从服务器，从服务器可以终止复制，所以可以在从服务器中进行数据不备份而不影响主服务器

高可用

因为主服务器和从服务器中的数据是一致的，所以当主服务器挂了之后，指定一台从服务器来充当主服务器保证服务继续运行。在主服务器上执行写入和更新，在从服务器中进行读取，达到读写分离的效果，同时可以动态调整从服务器的数量，从而调整整个数据库架构的性能在主服务器中生成数据，再从服务器中分析数据，从而提高主服务器的性能

机构扩展

随着系统架构的扩展，如果部署单个数据库库服务，就会导致IO访问频率过高。有了主从复制增加数据库节点，就可以将磁盘IO分布到多个节点上，提高单个机器的IO性能。

主从复制的形式

一主多从

提高系统的读性能

一主一从和一主多从是最常见的体系架构，实施起来简单且高效，不仅实现的高可用，还实现了读写分离，进而提升集群的并发能力。

多主一从（5.7开始支持）

多主一从可以将多台数据库备份到一台存储性能比较好的服务器 上

双主复制

每一台服务器即是master服务器，又是另外一台的slave服务器。这样任何一方所做的变更都可以通过复制到另一方服务器。

级联复制

级联模式下部分节点不是连接到主节点，而是连接到从节点。因为如果主节点连了太多的从节点就会损耗一部分性能用于Replication（复制）。那么我们可以让3~5个节点连到主节点，其他节点作为二级或者三级节点连到从节点上，这样既不会影响性能，也缓解了主节点的压力。级联模式下，从节点也要开启binlog功能。

MySQL主从复制原理

MySQL主从复制涉及到三个线程，一个运行在主节点中：log dump thread,还有两个运行在从节点中：IO thraed和SQL thread。如下图所示：

主节点log dump thread

当从服务器连接主服务器时，主服务器会为从服务器创建一个log dump thread,用于发送和读取bin log内容。log dump thread 读取bin log日志文件的时候会为bin log文件加锁，在读取完成，在发送给从服务器之前释放锁。主节点会为每一个连接自己的从节点创建一个log dump thread，log dump thread还会监听从服务器。

从节点IO thread

当从节点执行start slave命令之后，从节点会创建一个IO thread，请求主节点更新bin log,IO thread接收到主节点发送 过来的更新之后，保存到relay log中。

从节点SQL thread

SQL thread读取relay log中的内容，并解析成具体的执行语句并执行，最终达到主从数据库的一致性。

对于每一个主从连接都需要这三个线程来完成。当主节点有多个从节点时，主节点需要为每一个从节点创建一个dump log thread，而每一个从节点都有自己SQL thread和IO thread，从节点用这两个线程将从主节点拉取更新和执行分成两个独立的任务，这样在执行同步任务的时候不会降低读取数据的性能。比如，如果从节点没有运行，IO thread可以很快的从主节点拉去更新，尽管SQL线程没有执行。如果SQL线程还没有执行，这是从节点宕机了，由于IO线程已经将主节点的更新拉取到了本地并保存在relay log中，当从服务器启动的时候还可以完成数据同步。

要实施复制必须打开master的bin log功能，因为主从复制的本质就是就是将主节点中的bin log节点拉取到从节点，然后解析重做从而达到数据一致性（SQL执行是顺序执行的）。主从复制的过程如下所示：

主从复制的基本过程

在从节点上执行start slave 命令，开启主从粗制开关。从节点的IO线程连接到主节点，并从指定的文件中指定的位置开始复制。主节点中dump log线程会监听从节点中的IO线程,当IO线程请求同步更新时，dump log线程会读取指定文件指定位置之后的信息，返回给从节点。返回信息中除了包含日志信息之外还包含了当前bin log file和bin log position（偏移量，下一次复制的起始位置）。从节点中的IO线程接收到主节点的信息之后，将日志信息保存到relay-log中，将bin-log-file和bin-log-position保存到master-info中，以便下一次复制，通知主节点下一次复制的文件名及其起始位置。SQL线程监测到relay-log中添加了新内容，就会将relay-log解析成其在主节点实际执行的SQL语句，然后再从节点中顺序执行一遍，并再relay-log.info文件中记录当前中继日志文件名和为支点。主从复制模式

MySQL主从复制默认是异步复制模式。MySQL会把增删改操作记录到bin log中，当slave连接到master时，会主动从master中获取最新的bin log文件。并把bin log保存到relay log中，然后执行relay log的更新内容。

异步模式

这种节点主节点不追主动将bin log推送到从节点，主节点执行完并提交事务后，并不关心从节点是否已经接受并处理，而是直接将结果返回给客户端。那么这样就会有一个问题，如果主节点崩溃了，还没将bin log推送到从节点，此时如果强行将从节点切换为主节点，可能导致新主节点的数据不完整。异步模式下的主从复制过程如下图所示：

半同步模式

介于异步模式和全同步模式之间，主服务器处理完客户端提交的事务后不立即向客户端返回结果，而是等待至少一个从服务器接受并写入relay log中才返回执行成功信息到客户端（只能保证主服务器将bin log至少传输到一个从服务器，并不能保证从服务器执行该事务并更新到db），否则需要等待知道超时时间，转换为异步模式，将结果返回到客户端。相对于异步复制，一定程度上保证了数据的安全性，但是也会带来一定程度的延迟，但时比全同步延时要低，延时时间至少是一个TCP/IP连接时间。所以半同步使用于延时较低的环境下。

全同步模式

指当主库执行完一个事务，然后所有的从库都复制了该事务并成功执行完才返回成功信息给客户端。因为需要等待所有从库执行完该事务才能返回成功信息，所以全同步复制的性能必然会收到严重的影响。

异步模式，半同步模式和全同步模式对比图

GTID复制模式

即全局事务ID, 保证了在每个在主库上提交的事务在集群中有一个唯一的ID.

在传统的复制里面，当发生故障，需要主从切换，需要找到bin-log和pos点（指从库更新到了主库bin-log的哪个位置，这个位置之前都已经更显完毕，这个位置之后未更新），然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。在MySQL 5.6里面，不用再找bin-log和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找到同步点。

//GTID原理1、在原来基于日志的复制中, 从库需要告知主库要从哪个偏移量进行增量同步, 如果指定错误会造成数据的遗漏, 从而造成数据的不一致.2、而基于GTID的复制中, 从库会告知主库已经执行的事务的GTID的值, 然后主库会将所有未执行的事务的GTID的列表返回给从库. 并且可以保证同一个事务只在指定的从库执行一次.通过全局的事务ID确定从库要执行的事务的方式代替了以前需要用bin-log和pos点确定从库要执行的事务的方式。3、GTID是由server_uuid和事物id组成，格式为：GTID=server_uuid:transaction_id。server_uuid是在数据库启动过程中自动生成，每台机器的server-uuid不一样。uuid存放在数据目录的auto.conf文件中，而transaction_id就是事务提交时系统顺序分配的一个不会重复的序列号。4、主节点更新数据时，会在事务前产生GTID，一起记录到bin-log日志中。从节点的I/O线程将变更的bin-log，写入到本地的relay-log中。SQL线程从relay-log中获取GTID，然后对比本地bin-log是否有记录（所以MySQL从节点必须要开启binary-log）。如果有记录，说明该GTID的事务已经执行，从节点会忽略。如果没有记录，从节点就会从relay-log中执行该GTID的事务，并记录到binlog。在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。//GTID的好处1、GTID使用master_auto_position=1代替了binlog和position号的主从复制搭建方式，相比binlog和position方式更容易搭建主从复制。2、GTID方便实现主从之间的failover（主从切换），不用一步一步的去查找position和binlog文件。//GTID的局限性不能使用create table table_name  select * from table_name模式的语句在一个事务中既包含事务表的操作又包含非事务表不支持CREATE TEMPORARY TABLE  or DROP TEMPORARY TABLE语句操作使用GTID复制从库跳过错误时，不支持sql_slave_skip_counter参数的语法

Mysql 主从复制是mysql 高可用，高性能的基础，有了这个基础，mysql 的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活的调整。