MySQL主从复制原理（总和文章）

主从复制原理

文章一：

1、主从复制概述

MySQL主从复制也可以称为MySQL主从同步，它是构建数据库高可用集群架构的基础。它通过将一台主机的数据复制到其他一台或多台主机上，并重新应用relay log中的SQL语句来实现复制功能。MySQL支持单向、双向、链式级联、异步复制，5.5版本之后加入的半同步复制，5.6版本之后的GTID复制，MySQL5.7的多源复制、并行复制、loss-less复制。

1.1 常见的几种主从架构

1）单向主从模式：Master ——> Slave

2）双向主从模式：Master <====> Master

3）级联主从模式：Master ——> Slave1 ——> Slave2

4）一主多从模式

5）多主一从模式

1.2 主从复制功能

1）实时灾备

2）读写分离

3）高可用

4）从库数据统计

5）从库数据备份

6）平滑升级

1.3 主从复制原理

主从同步过程中主服务器有一个工作线程I/O dump thread，从服务器有两个工作线程I/O thread和SQL thread。

主库把外界接收的SQL请求记录到自己的binlog日志中，从库的I/O thread去请求主库的binlog日志，并将binlog日志写到中继日志中，然后从库重做中继日志的SQL语句。主库通过I/O dump thread给从库I/O thread传送binlog日志。
　　
　　2、复制原理

2.1 异步复制

异步复制是MySQL默认的复制方式，主库写入binlog日志后即可成功返回客户端，无须等待binlog日志传递给从库的过程，但是一旦主库宕机，就有可能出现丢失数据的情况。

2.2 半同步复制

MySQL默认的复制方式是异步复制，但是当主库宕机，在高可用架构坐准备切换，就会造成新的主库丢失数据的现象。

MySQL5.5版本之后引入了半同步复制，但是主从服务器必须同时安装半同步复制插件。在该功能下，确保从库接收完成主库传递过来的binlog内容已经写入到自己的relay log后才会通知主库上面的等待线程。如果等待超时(超时参数：rpl_semi_sync_master_timeout)，则关闭半同步复制，并自动转换为异步复制模式，直到至少有一台从库通知主库已经接收到binlog信息为止。

半同步复制原理图：
　　
　　　　半同步复制提升了主从之间数据的一致性，让复制更加安全可靠，在5.7 版本中又增加了rpl_semi_sync_master_wait_point参数，用来控制半同步模式下主库返回给session事务成功之前的事务提交方式。

该参数有两个值：

1）AFTER_COMMIT：5.6版本的默认值，主库将每个事务写入binlog，并传递给从库，刷新到中继日志中，同时主库提交事务。之后主库开始等待从库的反馈，只有收到从库的回复之后，master才将commit OK的结果反馈给客户端。

2）AFTER_SYNC：5.7版本新增，也是默认的半同步复制方式。主库将每个事务写入binlog并传递给从库，刷新到中继日志中，主库开始等待从库的反馈，接收到从库的回复之后，再提交事务并且返回commit OK结果给客户端。

注意：可以通过rpl_semi_sync_master_wait_for_slave_count参数来控制主库接收多少个从库写事务成功反馈，才返回成功给客户端。生产环境中使用半同步复制方式，当从库出现故障，等待超时的时间又很长，导致主库无法接收从库信息而无法正常写入时，可通过该参数剔除故障从库。另外rpl_semi_sync_master_timeout单位是毫秒，它表示如果主库等待从库回复消息的时间超过该值，就自动切换为异步复制模式，建议调整为很大，禁止向异步复制切换来保证数据复制的安全性。MySQL 5.7默认的半同步复制方式是after_sync模式。

在AFTER_SYNC模式下，即使主库宕机，所有在主库上已经提交的事务都能保证已经同步到从库的中继日志中，不会丢任何数据。

2.3 GTID复制

GTID又叫全局事务ID，是一个以提交事务的编号，并且是一个全局唯一的编号。GTID是由server_uuid和事务id组成的，即GTID=server_uuid:transaction_id。

server_uuid是数据库启动自动生成的，保存在auto.cnf文件下，transaction_id是事务提交时由系统顺序分配的一个不会重复的序列行。

GTID存在的价值：

1）GTID使用master_auto_position=1代替了基于binlog和position号的主从复制方式，更便于主从复制的搭建。

2）GTID可以知道事务在最开始是哪个实例上提交的。

3）GTID方便实现主从之间的failover，无须找position和binlog。

GTID限制条件：

1）不能使用create table table_name select * from table_name。

2）不支持CREATE TEMPORARY TABLE or DROP TEMPORARY TABLE语句操作。

3）不支持sql_slave_skip_counter。

文章二：

深度探索MySQL主从复制原理

概要

MySQL Replication (MySQL 主从复制) 是什么？

为什么要主从复制以及它的实现原理是什么？

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

MySQL 主从复制主要用途
l 读写分离

在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。

l 数据实时备份，当系统中某个节点发生故障时，可以方便的故障切换

l 高可用HA

l 架构扩展

随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能。

MySQL 主从形式
一主一从

一主多从，提高系统的读性能

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

多主一从 （从5.7开始支持）

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

双主复制

双主复制，也就是互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。

级联复制

级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。

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

l 主节点 binary log dump 线程

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

l 从节点I/O线程

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

l 从节点SQL线程

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

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

要实施复制，首先必须打开Master 端的binary log（bin-log）功能，否则无法实现。

因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。如下图所示：

复制的基本过程如下：

从节点上的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的内容解析成在祝节点上实际执行过的操作，并在本数据库中执行。

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

l 异步模式（mysql async-mode）

异步模式如下图所示，这种模式下，主节点不会主动push bin log到从节点，这样有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地。

l 半同步模式(mysql semi-sync)

这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长。如下图所示：

半同步模式不是mysql内置的，从mysql 5.5开始集成，需要master 和slave 安装插件开启半同步模式。

l 全同步模式

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

binlog记录格式
MySQL 主从复制有三种方式：基于SQL语句的复制（statement-based replication，SBR），基于行的复制（row-based replication，RBR)，混合模式复制（mixed-based replication,MBR)。对应的binlog文件的格式也有三种：STATEMENT,ROW,MIXED。

l Statement-base Replication (SBR)就是记录sql语句在bin log中，Mysql 5.1.4 及之前的版本都是使用的这种复制格式。优点是只需要记录会修改数据的sql语句到binlog中，减少了binlog日质量，节约I/O，提高性能。缺点是在某些情况下，会导致主从节点中数据不一致（比如sleep(),now()等）。

l Row-based Relication(RBR)是mysql master将SQL语句分解为基于Row更改的语句并记录在bin log中，也就是只记录哪条数据被修改了，修改成什么样。优点是不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是修改table的时候会让日志暴增,同时增加bin log同步时间。也不能通过bin log解析获取执行过的sql语句，只能看到发生的data变更。

l Mixed-format Replication(MBR)，MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上两种模式的混合，对于一般的复制使用STATEMENT模式保存到binlog，对于STATEMENT模式无法复制的操作则使用ROW模式来保存，MySQL会根据执行的SQL语句选择日志保存方式。

GTID复制模式
@ 在传统的复制里面，当发生故障，需要主从切换，需要找到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 主从复制是mysql 高可用，高性能的基础，有了这个基础，mysql 的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活的调整。

文章三：

Mysql主从复制作用和工作原理详解

一、什么是主从复制

主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库，主数据库一般是准实时的业务数据库。在最常用的mysql数据库中，支持单项、异步赋值。在赋值过程中，一个服务器充当主服务器，而另外一台服务器充当从服务器；此时主服务器会将更新信息写入到一个特定的二进制文件中。

并会维护文件的一个索引用来跟踪日志循环。这个日志可以记录并发送到从服务器的更新中去。当一台从服务器连接到主服务器时，从服务器会通知主服务器从服务器的日志文件中读取最后一次成功更新的位置。然后从服务器会接收从哪个时刻起发生的任何更新，然后锁住并等到主服务器通知新的更新。

二、主从复制的作用

一是确保数据安全；做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据的丢失。
二是提升I/O性能；随着日常生产中业务量越来越大,I/O访问频率越来越高，单机无法满足，此时做多库的存储，有效降低磁盘I/O访问的频率，提高了单个设备的I/O性能。
三是读写分离，使数据库能支持更大的并发；在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

三、主从复制的原理

主从复制中涉及的文件
主库: binlog
从库:
relaylog 中继日志
master.info 主库信息文件
relaylog.info relaylog应用的信息
主从复制中涉及的三个线程
主库:
Binlog_Dump Thread :
从库:
SLAVE_IO_THREAD
SLAVE_SQL_THREAD

具体原理如图所示：

1.从数据库执行change master to 命令(主数据库的连接信息+复制的起点)
2.从数据库会将以上信息,记录到master.info文件
3.从数据库执行 start slave 命令,立即开启SLAVE_IO_THREAD 和SLAVE_SQL_THREAD这两个线程

4.从数据库 SLAVE_SQL_THREAD,读取master.info文件中的信息获取到IP,PORT,User,Pass,binlog的位置信息
5.从数据库SLAVE_IO_THREAD请求连接主数据库,主数据库专门提供一个SLAVE_IO_THREAD,负责和SLAVE_SQL_THREAD交互
6.SLAVE_IO_THREAD根据binlog的位置信息,请求主数据库新的binlog
7.主数据库通过Binlog_DUMP_Thread将最新的binlog,通过网络TP给从数据库的SALVE_IO_THREAD
8.SLAVE_IO_THREAD接收到新的binlog日志,存储到TCP/IP缓存,立即返回ACK给主库,并更新master.info
9.SLAVE_IO_THREAD将TCP/IP缓存中数据,转储到磁盘relaylog中.
10.SLAVE_SQL_THREAD读取relay.info中的信息,获取到上次已经应用过的relaylog的位置信息
11.SLAVE_SQL_THREAD会按照上次的位置点回放最新的relaylog,再次更新relay.info信息
12.从数据库会自动purge应用过relay进行定期清理
一旦主从复制构建成功,主数据库当中发生了新的变化,都会通过 slave_dump_THREAD发送信号给SLAVE_IO_THREAD,增强了主从复制的实时性.

文章四：

mysql主从复制原理

MySQL的主从同步是一个很成熟的架构，优点为：①在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力;②在从主服务器进行备份，避免备份期间影响主服务器服务;③当主服务器出现问题时，可以切换到从服务器。

mysql 主(称 master)从(称 slave)复制的原理：
1、 master 将数据改变记录到二进制日志(binary log)中,也即是配置文件 log-bin
指定的文件(这些记录叫做二进制日志事件，binary log events)
2、 slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
3、 slave 重做中继日志中的事件，将改变反映它自己的数据(数据重演) —重新执行一下
4、默认 1 分钟同步一次

MySQL的主从同步一直有从库延迟的问题，那么为什么会有这种问题。这种问题如何解决呢？

1. MySQL数据库主从同步延迟原理。

2. MySQL数据库主从同步延迟是怎么产生的。

3. MySQL数据库主从同步延迟解决方案。

4. MySQL数据库主从同步延迟原理。

答：谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理说起，mysql的主从复制都是单线程的操作，主库对所有DDL和DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率很比较高，下一步，问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。

2. MySQL数据库主从同步延迟是怎么产生的。

答：当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。

3. MySQL数据库主从同步延迟解决方案

答：最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。

mysql-5.6.3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，Oracle使用的是以数据库(schema)为单位做多线程，不同的库可以使用不同的复制线程。

sync_binlog=1

This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction

默认情况下，并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢 失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog写入后与硬盘 同步。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表，MySQL服务器 处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍 然存在binlog中。可以用–innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。(注释：在MySQL 5.1中不需要–innodb-safe-binlog；由于引入了XA事务支持，该选项作废了），该选项可以提供更大程度的安全，使每个事务的 binlog(sync_binlog =1)和(默认情况为真)InnoDB日志与硬盘同步，该选项的效果是崩溃后重启时，在滚回事务后，MySQL服务器从binlog剪切回滚的 InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等，并使从服务器保持与主服务器保持同步(不接收 回滚的语句)。

innodb_flush_log_at_trx_commit （这个很管用）

抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电 池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。

解决之道：分布式集群
2016 年 8 月 30 号腾讯开源了 PhxSQL 产品。
PhxSQL 是由微信后台团队自主研发的一款服务高可用、数据强一致的分布式数据库服
务。该服务基于 Percona5.6 搭建，目标在于解决 MySQL 在容灾和数据一致性方面的不足，
并大幅简化了 MySQL 容灾切换的运维操作。
PhxSQL 具有服务高可用、数据强一致、高性能、运维简单、和 MySQL 完全兼容的特点。
服务高可用：PhxSQL 集群内只要多数派节点存活就能正常提供服务；出于性能的考虑，集
群会选举出一个 Master 节点负责写入操作；当 Master 失效，会自动重新选举新的 Master。
数据强一致：PhxSQL 采用多节点冗余部署，在多个节点之间采用 paxos 协议同步流水，保
证了集群内各节点数据的强一致。
下载地址：https://github.com/tencent-wechat/phxsql

主从配置需要注意的地方
1、 主 DB server 和从 DB server 数据库的版本一致。
2、 主 DB server 和从 DB server 数据库数据一致[ 这里就会可以把主的备份在从上
还原，也可以直接将主的数据目录拷贝到从的相应数据目录]。
3、 主 DB server 开启二进制日志,主 DB server 和从 DB server 的 server_id 都
必须唯一。

文章五：

MySQL主从复制原理解析

MySQL的主从复制是一个异步的复制过程（虽然一般情况下感觉是实时的），数据将从一个MySQL数据库复制到另一个MySQL数据库，在master与Slave之间实现整个主从复制的过程是有三个线程参与完成的。其中两个线程（SQL线程和IO线程）在slave端，另一个线程（I/O线程）在master端。

复制概述

MySQL内置的复制功能是构建大型、高性能应用程序的基础。将MySQL的数据分布到多个系统上去，这种分布的机制，是通过将MySQL的某一台主机的数据复制到其它主机（slave）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。

注：当进行复制时，所有对复制中表的更新必须在主服务器上进行。否则，你必须要小心，以避免对主服务器上的表进行的更新与对从服务器上的表的更新之间的冲突。

MySQL复制的应用常见场景？

    1、从服务器作为主服务器的实时数据备份

    2、主从服务器实现读写分离，从服务器实现负载均衡

    3、把多个从服务器根据业务重要性进行拆分访问

主从复制实现基本原理？

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

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

    3、从属服务器从主服务器请求该二进制日志并在本地应用其内容。即通过把主库的binlog传送到从库，从新解析应用到从库。

MySQL支持的复制类型

（1）基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。

        一旦发现没法精确复制时，会自动选择基于行的复制。

（2）基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍。从MySQL5.0开始支持。

（3）混合类型复制：默认采用基于语句的复制，一旦发现基于语句无法精确复制时，就会采用基于行的复制。

复制解决的问题

1、数据分布（data distribution） 2、负载均衡（load balancing）

3、备份（backups） 4、高可用和容错行（high availability and failover）

复制过程

1、从库通过手工执行change master to 语句连接主库，提供了连接的用户一切条件（user 、password、port、ip），并且让从库知道，二进制日志的起点位置（file名 position 号）； start slave

2、从库的IO线程和主库的dump线程建立连接。

3、从库根据change  master  to 语句提供的file名和position号，IO线程向主库发起binlog的请求。

4、主库dump线程根据从库的请求，将本地binlog以events的方式发给从库IO线程。

5、从库IO线程接收binlog  events，并存放到本地relay-log中，传送过来的信息，会记录到master.info中

6、从库SQL线程应用relay-log，并且把应用过的记录到relay-log.info中，默认情况下，已经应用过的relay 会自动被清理purge

主从复制状态失败原因？

1、主机没启动，或者宕机，检查主库状态。

2、网络通信问题，使用ping命令检查；或使用shell命令进行shell端登录测试。

3、防火墙，selinux

4、复制用户名、密码、端口号、地址有问题，使用MySQL命令进行shell端登录测试。

5、MySQL自动解析，会将连接的IP解析成主机名（skip-name-resolve=0）写入my.cnf文件即可。

6、从库IO异常关闭，通过show slave  status\G进行查看

文章六：

MySQL主从复制原理

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

1.主库db的更新事件(update、insert、delete)被写到binlog
2.主库创建一个binlog dump thread，把binlog的内容发送到从库
从库启动并发起连接，连接到主库
从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
从库启动之后，创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

注：上述流程为相对流程，并非绝对流程

文章七：

MySQL主从复制的原理

MySQL主从复制是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。

binlog：binary log，主库中保存所有更新事件日志的二进制文件。binlog是数据库服务启动的一刻起，保存数据库所有变更记录（数据库结构和内容）的文件。在主库中，只要有更新事件出现，就会被依次地写入到binlog中，之后会推送到从库中作为从库进行复制的数据源。

binlog输出线程：每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。 对于每一个即将发送给从库的sql事件，binlog输出线程会将其锁住。一旦该事件被线程读取完之后，该锁会被释放，即使在该事件完全发送到从库的时候，该锁也会被释放。

在从库中，当复制开始时，从库就会创建从库I/O线程和从库的SQL线程进行复制处理。

从库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，随时准备在从库下一次启动的时候执行语句。

文章八：

Mysql主从复制原理 （简化版）

在实际的生产环境中，如果对mysql数据库的读和写都在一台数据库服务器中操作，无论是在安全性、高可用性，还是高并发等各个方面都是不能满足实际需求的。因此，一般通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。

Mysql主从复制和读写分离

l 主从复制：

Mysql的主从复制和mysql的读写分离两者有紧密的联系，首先要部署主从复制，只有主从复制完成了，才能再此基础上进行数据的读写分离。

Mysql支持的复制类型：

1、 基于语句的复制：在主服务器上执行的sql语句，在从服务器上会执行同样的语句。Mysql默认采用基于语句的复制，效率比较高，但是有时不能实现精准复制。

2、 基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍。

3、 混合类型的复制：默认采用基于语句的复制，一旦发现基于语句的复制不能精准复制时，就会采用基于行的复制。

l 主从复制的过程：

1、 在每个事物更新数据完成之前，master在二进制日志记录这些改变，写入二进制日志完成后，master通知存储引擎提交事物。

2、 Slave将master的binary log复制到其中的中继日志。首先从mysql服务器开始一个工作线程I/O线程，I/O线程在master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从master的二进制日志中读取事件，如果已经跟上master。他会睡眠并等待master产生新的事件。I/O线程将这些事件写入中继日志。

3、 Sql从线程处理该过程的最后一步。Sql线程从中继日志中读取事件，并重放其中的事件而更新slave的数据，使其与master的数据一致。

二 ································································································································································

主从复制的形式：

l 一主一从

l 主主复制（互为主从）

l 一主多从—扩展系统读取的性能，因为读是在从库读取的；

l 多主一从—从5.7开始支持

使用环境、用途、优点、缺点：

l 实时灾备，用于故障切换

l 热备份，避免影响业务

l mysql主从复制是mysql高可用性，高性能（负载均衡）的基础

l 简单，灵活，部署方式多样，可以根据不同业务场景部署不同结构

l 在业务复杂的系统中，有这么一个情景，有一句sql语句需要锁表，导致暂时不能使用读的服务，那么就很影响运行中的业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。

l 架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

l 复制过程中应该时刻监控复制状态，复制出错或延时可能给系统造成影响

l 如果单做主从复制，可能造成一定的资源浪费

l 主从复制并不是完美的架构，根据业务量或者其他因素的不同，可能会有各种误差出现

主从原理：

主从复制的基础是主库记录数据库的所有变更记录到binlog。binlog是数据库中保存配置中过期时间内所有修改数据库结构或内容的一个文件。如果过期时间是10d的话，那么就是最近10d的数据库修改记录。

mysql主从复制是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。在主库里，只要有更新事件出现，就会被依次地写入到binlog里面，是之后从库连接到主库时，从主库拉取过来进行复制操作的数据源。

binlog输出线程：每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。对于每一个即将发送给从库的sql事件，binlog输出线程会将其锁住。一旦该事件被线程读取完之后，该锁会被释放，即使在该事件完全发送到从库的时候，该锁也会被释放。

从库生成两个线程，一个I/O线程，一个SQL线程；

I/O线程：去请求主库 的binlog(二进制日志)，并将得到的binlog日志写到relay log（中继日志） 文件中；主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；

SQL 线程：会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；

大概步骤：

l 步骤一：主库db的更新事件(update、insert、delete)被写到binlog

l 步骤二：从库发起连接，连接到主库

l 步骤三：此时主库创建一个binlog dump thread，把binlog的内容发送到从库

l 步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log

l 步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db

文章九：

MySQL主从复制作用和原理（好理解）

一、什么是主从复制?
主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库。

二、主从复制的作用
1、做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
2、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
3、读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。

三、主从复制的原理
1.数据库有个bin-log二进制文件，记录了所有sql语句。
2.我们的目标就是把主数据库的bin-log文件的sql语句复制过来。
3.让其在从数据的relay-log重做日志文件中再执行一次这些sql语句即可。
4.下面的主从配置就是围绕这个原理配置
5.具体需要三个线程来操作：
1.binlog输出线程:每当有从库连接到主库的时候，主库都会创建一个线程然后发送binlog内容到从库。在从库里，当复制开始的时候，从库就会创建两个线程进行处理：
2.从库I/O线程:当START SLAVE语句在从库开始执行之后，从库创建一个I/O线程，该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件，其中包括relay log文件。

3.从库的SQL线程:从库创建一个SQL线程，这个线程读取从库I/O线程写到relay log的更新事件并执行。

可以知道，对于每一个主从复制的连接，都有三个线程。拥有多个从库的主库为每一个连接到主库的从库创建一个binlog输出线程，每一个从库都有它自己的I/O线程和SQL线程。
主从复制如图：

原理图2,帮助理解!

步骤一：主库db的更新事件(update、insert、delete)被写到binlog
步骤二：从库发起连接，连接到主库
步骤三：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库
步骤四：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log.
步骤五：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db.