mysql主从三个线程工作顺序_MySQL主从同步原理介绍

原标题：MySQL主从同步原理介绍

摘要：这篇文章主要介绍了MySQL主从同步原理介绍，本文讲解了主从同步概述、主从同步需求、主从同步过程等内容，需要的朋友可以参考下。

概述

Mysql的Replication(复制)是一个异步的复制过程，从一个 Mysqlinstance(我们称之为Master)复制到另一个Mysqlinstance(我们称之Slave)在Master与Slave之间的 实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在Slave端，另外一个线程(IO线程)在Master端。

主从同步需求

要实现MySQL的Replication,首先必须打开Master端的 BinaryLog(mysql-bin.xxxxxx)功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在 自己身上完全顺序的执行日志中所记录的各种操作。打开MySQL的BinaryLog可以通过在启动MySQLServer的过程中使用“—log- bin”参数选项，或者在my.cnf配置文件中的mysqld参数组([mysqld]标识后的参数部分)增加“log-bin”参数项。

主从同步过程

MySQL复制的基本过程如下：

1.Slave上面的IO线程连接上Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容；

2.Master接收到来自Slave的IO线程的请求后，通过负责复制的IO线程根据请求信 息读取指定日志指定位置之后的日志信息，返回给Slave端的IO线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在Master端的 BinaryLog文件的名称以及在BinaryLog中的位置；

3.Slave的IO线程接收到信息后，将接收到的日志内容依次写入到Slave端的 RelayLog文件(mysql-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到 master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给 我”。

4.Slave的SQL线程检测到RelayLog中新增加了内容后，会马上解析该Log文件 中的内容成为在Master端真实执行时候的那些可执行的Query语句，并在自身执行这些Query.这样，实际上就是在Master端和Slave端 执行了同样的Query，所以两端的数据是完全一样的。

实际上，在老版本中，MySQL的复制实现在Slave端并不是由SQL线程和IO线程这两个线程共同协作而完成的，而是由单独的一个线程来完成所有的工作。但是MySQL的工程师们很快发现，这样做存在很大的风险和性能问题，主要如下：

1.首先，如果通过一个单一的线程来独立实现这个工作的话，就使复制Master端的，BinaryLog日志，以及解析这些日志，然后再在自身执行的这个过程成为一个串行的过程，性能自然会受到较大的限制，这种架构下的Replication的延迟自然就比较长了。

2.其次，Slave端的这个复制线程从Master端获取BinaryLog过来之后，需要 接着解析这些内容，还原成Master端所执行的原始Query，然后在自身执行。在这个过程中，Master端很可能又已经产生了大量的变化并生成了大 量的BinaryLog信息。如果在这个阶段Master端的存储系统出现了无法修复的故障，那么在这个阶段所产生的所有变更都将永远的丢失，无法再找回 来。这种潜在风险在Slave端压力比较大的时候尤其突出，因为如果Slave压力比较大，解析日志以及应用这些日志所花费的时间自然就会更长一些，可能 丢失的数据也就会更多。

所以，在后期的改造中，新版本的MySQL为了尽量减小这个风险，并提高复制的性能，将 Slave端的复制改为两个线程来完成，也就是前面所提到的SQL线程和IO线程。最早提出这个改进方案的是Yahoo！的一位工程 师"JeremyZawodny”。通过这样的改造，这样既在很大程度上解决了性能问题，缩短了异步的延时时间，同时也减少了潜在的数据丢失量。

当然，即使是换成了现在这样两个线程来协作处理之后，同样也还是存在Slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事务中，这些问题都是存在的。

总结

初步了解了MySQL主从复制的原理。

推荐：

责任编辑：