mysql主从同步过程 同步原理

Replication 线程
　 　Mysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的告终全副复制过程重要由三个线程来告终，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。
　　要告终 MySQL 的 Replication ，率先定然敞开 Master 端的Binary Log(mysql-bin.******)功能，否则无法告终。因为全副复制过程切实上即便Slave从Master端获得该日志然后再在自己身上全面 次序的厉行日志中所登记的各种垄断。敞开 MySQL 的 Binary Log 能够穿越在启用 MySQL Server 的过程中利用 “—log-bin” 参数选项，可能在 my.cnf 搭配文件中的 mysqld 参数组([mysqld]标识后的参数局部)添置 “log-bin” 参数项。
　　MySQL 复制的大约过程如下：
　　1. Slave 上面的IO线程连接上 Master，并哀求从指定日志文件的指定位置(可能从最开始的日志)尔后的日志内容;
　 　2. Master 接收到来自 Slave 的 IO 线程的哀求后，穿越负责复制的 IO 线程依据哀求消息读取指定日志指定位置尔后的日志消息，归来给 Slave 端的 IO 线程。归来消息中除非日志所包括的消息之外，还包括鄙碌回的消息在 Master 端的 Binary Log 文件的名目以及在 Binary Log 中的位置;
　　3. Slave 的 IO 线程接收到消息后，将接收到的日志内容顺次写入到 Slave 端的Relay Log文件(mysql-relay-bin.******)的最末路，并将读取到的Master端的bin-log的文件名和位置登记到master- info文件中，以便在下顺次读取的时候能够打听的高速Master“我必需从某个bin-log的哪个位置开始后来的日志内容，请发给我”
　 　4. Slave 的 SQL 线程检测到 Relay Log 中新添置了内容后，会即刻解析该 Log 文件中的内容成为在 Master 端诚厉行行时候的那些可厉行的 Query 语句，并在切身厉行这些 Query。这么，切实上即便在 Master 端和 Slave 端厉行了同样的 Query，因而两端的数据是全面一样的。
　　切实上，在老版本中，MySQL 的复制告终在 Slave 端并不是由 SQL 线程和 IO 线程这两个线程共同配合而告终的，而是由独自的一个线程来告终所有的工作。然而 MySQL 的工程师们很快觉察，这么做存在很大的危险和功能问题，重要如下：
　 　率先，万一穿越一个单一的线程来自力更生告终这个工作的话，就使复制 Master 端的，Binary Log日志，以及解析这些日志，然后再在切身厉行的这个过程成为一个串行的过程，功能慷慨会受到较大的局限，这种架构下的 Replication 的迟到慷慨就比拟长了。
　 　其次，Slave 端的这个复制线程从 Master 端获得 Binary Log 到来尔后，必需随后解析这些内容，还原成 Master 端所厉行的原始 Query，然后在切身厉行。在这个过程中，Master端很可能又曾经发生了许多的改变并生成了许多的 Binary Log 消息。万一在这个阶段 Master 端的存储系统揭示了无法修复的故障，那么在这个阶段所发生的所有改变都将永远的失落，无法再找归来。这种埋伏危险在Slave 端压力比拟大的时候尤其冒尖，因为万一 Slave 压力比拟大，解析日志以及利用这些日志所花费的工夫慷慨就会更长一些，可能失落的数据也就会更多。
　 　因而，在后期的改革中，新版本的 MySQL 为了尽量减小这个危险，并长进复制的功能，将 Slave 端的复制改为两个线程来告终，也即便前面所提到的 SQL 线程和 IO 线程。最早提出这个改进计划的是Yahoo!的一位工程师“Jeremy Zawodny”。穿越这么的改革，这么既在很大程度上处理了功能问题，缩小了异步的延随工夫，同时也收缩了埋伏的数据失落量。
　　当然，即便是换成了目前这么两个线程来配合处理尔后，同样也还是存在 Slave 数据延时以及数据失落的可能性的，终究这个复制是异步的。凡是数据的改动不是在一个事务中，这些问题都是存在的。
　　万一要全面避免这些问题，就只能用 MySQL 的 Cluster 来处理了。不过 MySQL的 Cluster 懂得笔者写这局部内容的时候，依旧还是一个内存数 据库的处理计划，也即便必需将所有数据包括索引全副都 Load 到内存中，这么就对内存的要求就极其大的大，对于等闲的公众化利用来说可厉行性并不是太大。当然，在之前与 MySQL 的 CTO David 沟通的时候得知，MySQL 目前正在不时改进其 Cluster 的告终，其中极其大的一个修改即便批准数据无须全副 Load 到内存中，而仅仅只是索引全副 Load 到内存中，我想信在告终该项改革尔后的 MySQL Cluster 将会更加受人迎接，可厉行性也会更大