Mysql主从复制（一）原理介绍

`官方文档`

Mysql主从复制（MySQL Replication）见官方文档17章介绍：Chapter 17 Replication

`Mysql主从复制概念`

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

`Mysql主从复制好处`

读写分离，使数据库能支持更大的并发；在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。
数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换
高可用HA，确保数据安全，做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据的丢失
架构扩展，随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能。
Mysql 主从复制是mysql 高可用，高性能的基础，有了这个基础，mysql 的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活的调整。

`Mysql主从复制原理`

MySQL主从复制涉及到三个线程，一个运行在主节点（binlog_dump thread），其余两个(I/O thread, SQL thread)运行在从节点，如下图所示

主节点binary log dump 线程

当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发送动给从节点之前，锁会被释放。

从节点I/O线程
当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。

从节点SQL线程
SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。

对于每一个主从连接，都需要三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，而每个从节点都有自己的I/O进程，SQL进程。从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。比如，如果从节点没有运行，此时I/O进程可以很快从主节点获取更新，尽管SQL进程还没有执行。如果在SQL进程执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当服务再次起来之后，就可以完成数据的同步。

复制的基本过程

从节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”；
Slave 的 SQL线程检测到relay-log 中新增加了内容后，会将relay-log的内容解析成在主节点上实际执行过的操作，并在本数据库中执行。

各种文件介绍，详见17.2.4.2 Slave Status Logs
relay log：我们在上文中已经提到，slave IO线程从master读取的binlog数据首先保存在本地的relay log中；此后SQL线程即可从relay log中读取变更操作并在本地应用。严格意义上说，relay log的内容应该与master binlog逐字节一致的（byte-to-byte）。

master info：master-info log文件保存了slave与当前master建立链接的一些配置信息和链接状态，日志中包括：master的host名称、login认证信息，以及slave读取master binlog的位置信息。在5.6之前，信息保存在master.info文件中，5.6之后，可以通过“–master-info-repository=TABLE”启动参数（或者配置文件）将信息保存在“mysql.slave_master_info”系统表中。

relay log info：用于记录relay log执行点的状态信息，在5.6之前默认写入relay-log.info文件，5.6之后可以通过“–relay-log-info-repository=TABLE”将信息写入“mysql.slave_relay_log_info”系统表中。为了避免crash对数据带来的不一致问题，强烈建议将master-info、relay-log-info采用事务性表，而且建议开启“–relay-log-recovery”。不过很遗憾的是，在5.6.5之前的版本中，slave_master_info、slave_relay_log_info表默认为MyISAM，需要手动修改为InnoDB。

binlog：这个大家都很熟悉，slave上也可以开启binlog功能，比如slave是其他slave的master时。relay log内容格式与binlog一样，也可以使用mysqlbinlog shell查看。

`MySQL主从复制模式`

异步模式（Asynchronous）
MySQL主从复制默认是异步模式。MySQL增删改操作会全部记录在binary log中，当slave节点连接master时，会主动从master处获取最新的bin log文件并把bin log中的sql relay。

异步模式，无法保证当master失效后所有的updates已经复制到了slaves上，只有重启master才能继续恢复这些数据，如果master因为宿主机器物理损坏而无法修复，那些尚未复制到slaves上的updates将永久性丢失；因此异步方式存在一定的数据丢失的风险，但它的优点就是master支持的write并发能力较强，因为master上的writes操作与slaves的复制是互为独立的。

这种模式，slaves总有一定的延后，这种延后在事务操作密集的应用中更加明显，不过通常这种延后时间都极其短暂的。从另一个方面来说，异步方式不要求slaves必须时刻与master建立链接，可能slaves离线、中断了replication进程或者链接的传输延迟很高，这都不会影响master对writes请求的处理效率。

半同步模式（Semi-synchronous）
“半同步”并不是MySQL内置的replication模式，而且由插件实现，即在使用此特性之前，需要在master和slaves上安装插件，且通过配置文件开启“半同步”。当slave与master建立连接时会表明其是否开启了“半同步”特性；此模式正常运作，需要master和至少一个slaves同时开启，否则仍将采用“异步”复制。

与异步复制相比，半同步提高了数据一致性，降低了数据丢失的风险。但是它也引入了一个问题，就是master阻塞等待slaves的确认信息，在一定程度上降低了master的writes并发能力，特别是当slaves与master之间网络延迟较大时；因此我们断定，半同步slaves应该部署在与master临近的网络中，为了提高数据一致性，我们有必要将半同步作为replication的首选模式。

在实际的部署环境中，并不要求所有的slaves都开启半同步，我们可以将与master临近的slaves开启半同步，将那些“远距分布”的slaves使用异步。

这种模式下在master上执行事务提交的线程，在事务提交后将会阻塞，直到至少一个“半同步”的slave返回确认消息（ACK）或者所有的半同步slave都等待超时；slave将接收到事务的信息写入到本地的relay log文件且flush到磁盘后，才会向master返回确认消息，需要注意slave并不需要此时就执行事务提交，此过程可以稍后进行。当所有的半同步slaves均在指定的时间内没有返回确认消息，即timeout，那么此后master将转换成异步复制模式，直到至少一个半同步slave完全跟进才会转换为半同步模式。在master阻塞结束后才会返回给客户端执行的状态，此期间不会处理其他的事务提交，当write请求返回时即表明此操作在master上提交成功，且在至少一个半同步slaves也复制成功或者超时，阻塞超时并不会导致事务的rollback。如下图所示：

全同步模式
主节点和从节点全部执行了commit并确认才会向客户端返回成功。

`binlog记录格式`

MySQL 主从复制有三种方式：

基于SQL语句的复制（statement-based replication，SBR），对应的binlog文件的格式STATEMENT，记录sql语句在bin log中，Mysql 5.1.4 及之前的版本都是使用的这种复制格式。优点是只需要记录会修改数据的sql语句到binlog中，减少了binlog日志量，节约I/O，提高性能。缺点是在某些情况下，会导致主从节点中数据不一致（比如sleep(),now()等）
基于行的复制（row-based replication，RBR)，对应的binlog文件的格式ROW，Mysql master将SQL语句分解为基于Row更改的语句并记录在bin log中，也就是只记录哪条数据被修改了，修改成什么样。优点是不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是修改table的时候会让日志暴增,同时增加bin log同步时间。也不能通过bin log解析获取执行过的sql语句，只能看到发生的data变更
混合模式复制（mixed-based replication,MBR)。对应的binlog文件的格式MIXED，MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上两种模式的混合，对于一般的复制使用STATEMENT模式保存到binlog，对于STATEMENT模式无法复制的操作则使用ROW模式来保存，MySQL会根据执行的SQL语句选择日志保存方式

`GTID复制模式`

GTID全名为Global Transaction Identifiers，全局事务性ID。在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。在MySQL 5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步。多线程复制（基于库），在MySQL 5.6以前的版本，slave的复制是单线程的。一个事件一个事件的读取应用。而master是并发写入的，所以延时是避免不了的。唯一有效的方法是把多个库放在多台slave，这样又有点浪费服务器。在MySQL 5.6里面，我们可以把多个表放在多个库，这样就可以使用多线程复制。

基于GTID复制实现的工作原理

主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中
从节点的I/O线程将变更的bin log，写入到本地的relay log中
SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log），如果有记录，说明该GTID的事务已经执行，从节点会忽略，如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log
在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描

`Mysql主从形式`

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

一主一从
一主多从
提高系统的读性能
多主一从
从5.7开始支持，多主一从可以将多个mysql数据库备份到一台存储性能比较好的服务器上
双主复制
也就是互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中，这种模式不建议采用，对于多点写入的架构模式（write操作密集型），建议采用MySQL Cluster！这种方式总是会引入“锁并发”、“数据不一致”等问题，仅供参考！（3M架构）
级联复制
级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响