MySQL之主从复制的过程和原理

ter23

  前几天搭建了MySQL的主从复制，已经搭建完成，但是主从复制的原理还不知道，所以来研究一下。    本文的部分内容来自于互联网。
    主从复制的过程
    首先要了解到的是一个单向主从复制的实现是由三个线程来完成，master一个IO线程，slave一个IO
线程和一个SQL线程。
    1. slave 上面的IO线程连接上 master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;
    2. master 接收到来自 slave 的IO线程的请求后，通过负责复制的IO线程根据请求信息读取指定日志指定位置之后的日志信息，返回给slave端的IO线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在master端的bin-log文件的名称以及在bin-log中的位置;
    3. slave的IO线程接收到信息后，将接收到的日志内容依次写入到slave端的Relay Log文件(hostname-relay-bin.xxxxxx)的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中，以便在下一次读取的时候能够清楚的告诉master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”
　 4. slave的SQL线程检测到Relay Log中新增加了内容后，会马上解析该Log文件中的内容成为在 master 端真实执行时候的那些可执行的Query 语句，并在自身执行这些Query。这样，实际上就是在 master 端和slave 端执行了同样的Query，所以两端的数据是完全一样的。
    下面是实际的操作图
    1.首先看一下主库的状态


2.然后看一下从库中master.info和nginx-relay-bin.000008（请无视名字，这个跟主机名有关）



master.info中一部分文件内容，跟master的bin-log的名称和位置是一致的


然后是nginx-relay-bin.000008的文件（有删节）



然后主库建一个库测试一下


看一下从库的master.info和nginx-relay-bin.000008文件


nginx-relay-bin.000008文件


现在我们来模拟一下故障，此时从数据库宕机，此时master.info文件不变，但是nginx-relay-bin.000008文件产生变化


主数据库新建一个库测试一下，


现在启动从数据库，此时relay-bin日志会重新产生两个，查看一下数值大的那个


查看nginx.relay-bin.000010



此时master.info文件也会更新到最新的pos

故障模拟完成。
写到这里，突然感觉写的实在是太繁琐了，详细一点也好，保证大家能看明白，不会云里雾里的感觉。

--------------------------------------分割线-----------------------------------------
说一下自己做实验时一些小细节
1.搭建完单向主从的时候，在主库创建了一个库sunys01做测试，然后在从库删掉了他，此时的主从数据不一致，但是主从还是正常的，主库再建一个库，从库也能同步的到数据。我一直以为主从同步只要是在从库进行过操作就会导致主从断掉。现在接上面的情况，从库删掉了sunys01，在主库也删掉sunys01，此时主从断裂，主库写数据从库无法同步数据， 现在我在从库重新创建了一个sunys01库，重启一下mysql，主从恢复了，主库中后续数据也成功同步。

2.做了一个双向主从在主1创建新库，同时他的master status变掉了，主1创建的库在主2也有，但是主2的master status也变掉了。我同学也是做的双主，但是主2的master status是不会变的，不知道是什么原因