Mysql主从分离的实现理论讲解

一.为何要使用主从库分离

  大型网站为了减轻服务器处理海量的并发访问所产生的性能问题，采用了很多的解决方案，其中最主流的方案之一就是读写分离，即将读操作和写操作分别倒流到不同的服务器集群去执行，到了数据业务层，数据访问层，如果还是传统的单靠一台服务器去抗，面对如此多的数据库连接操作，数据库必然会崩溃，如若造成数据的丢失，后果不堪设想。

二.主从同步工作的三个步骤

1. 主服务器(Master)将对数据的操作记录到二进制日志(Binary log)当中,也就是说在每个事务更新数据完成之前，Master在Binary log中记录这些改变，Mysql将事务串行的写入Binary log中，在事件写入Binary log完成之后，Master通知存储引擎提交事务，提交好事务后进入第二步，需要补充的是,对数据的操作就称之为一次Binary log的事件，称之为二进制日志事件（Binary Log Events）。
2. 从服务器(Slave)将Master的Binary Log Events拷贝到它的中继日志(Relay log)当中，首先Slave会开始一个工作线程I/O thread，I/O thread在Master上打开一个普通的连接，然后将Binary log 拷贝到I/O thread,从Master的Binary log中读取事件，如果已经跟上Master的话，此I/O thread便会睡眠并等待Master产生新的事件，I/O thread 就会将这些事件写入Relay log中。
3. Slave重做Binary Log Events。例如Master对数据进行了操作而Slave还未进行，此时Slave便需要重做一遍Master的操作。处理该过程的线程为SQL thread,SQL thread从中继日志读取(Read)事件并重放(Replay)其中的事件,做到更新Slave中的数据，使其与Master的中的数据一致。

三.为何不能将Master的Binary log直接读取到Slave中？

  从计算机的设计合理角度来说，是需要队列去处理信息的，由于网络等各种原因，Binary log 并不能一口气直接传送到Slave，因此为了不影响Slave执行其他操作，便会创建一个I/O thread，去接收Binary log 传送过来的数据，再将数据存入到Slave中的Relay log当中。Relay log类似于生产者消费者之间的一个桥梁，用来缓存Binary log传递过来的操作。实际上Reloy log本身也是存储在Slave中的缓存当中，因此他的开销很小。SQL thread作为一个消费者，它会异步的从Relay log当中读取数据出来取消费，也就是将Relay log中的操作实际的写入到Slave中。这样通过生产者消费者模式，能够达到不相互影响，又能让Slave继续去做别的事情