一条命令带你体验mysql的主从复制之旅

MYSQL的主从复制之旅（一）——戏说MySQL Statement-based 主从复制

我是一条数据更改操做，来自SQL家族。今天呀，我要来描述一段旅程，经过这段旅程，我才发现原来从主库（master）走到从库（slave）这么的不简单。
今天早上我从主库（master）肯定要出发后，首先被要求到一个叫作二进制日志（binary log）的小册子中进行了登记，接着就和其余兄弟姐妹一块儿等待着被送往今天的目的地——从库（slave）。
在这里得要说明一下，并非全部人都有资格到binary log登记，只有即将执行完毕而且改变了master数据的SQL语句，也就是说只有那些已经准备好出发前往slave的人才会被记录在binary log中。
在我登记完之后，master的业务人员（dump线程）就从binlog中读取个人信息，并发送给了slave的接送人员（I/O线程），通知他把我安 全的接到slave上。I/O线程带我来到slave，让我在slave的登记手册——中继日志（relay log）再次登记，而且告诉我，他还须要去接个人同伴，让我等待配送人员（SQL线程）的进一步安排。到目前为止，我还只是从master的binary log中被复制到了slave 的relay log。
SQL线程姗姗来迟，“抱歉让你久等了，刚处理完你朋友的需求。咱们这儿只有两位工做人员，一个负责配送，一个负责接待，只能一个一个串行处理，速度怎么 也快不起来。”就这样，我由SQL线程带领着，在slave上从新执行了一遍，将对master的数据改变复制到了slave上，个人旅程也就此告一段 落。

你必定很好奇，天天有那么多的SQL被写入到master上，master和slave的配送和接待人员是怎么在茫茫人海之中找到个人呢？
这得从我到binary log登记那里提及。Binary log并非一个单独的文件，它更像一个图书馆，保存了一组登记了咱们SQL信息的二进制日志文件（binary log file）和一个用来查找跟踪binary log file的索引，你们叫它binary log index。而我到slave上登记的中继日志（relay log）中除了包含二进制日志中的内容文件（relay log file）和索引文件（relay log index）之外，还有两个很是重要的文件：中继日志信息文件（relay-log.info）和master日志信息文件（master.info）。 去master接谁，带领谁到slave上执行，就全靠他们提供的跟踪信息啦！
master.info文件其实就是slave和master沟通的纽带，它记录着slave和master创建主从复制时全部必需的信息，而且细心的把 咱们在master上的位置给记录下来。这样哪怕master和slave短期失去联系了，slave的接送人员也知道下一个要到达slave的是谁。
relay-log.info文件应该算做是slave上接待人员SQL线程的工做笔记。每次带领一条SQL完成在slave的执行之后，SQL线程就会在这里记上一笔。这样当他休息后再恢复工做时就能准确的找到下一个要派送执行的SQL。

我曾经很担忧会在去往slave的路上走丢，可是看了slave工做人员的工做制度之后就一点儿也不担忧了。Slave上的I/O线程每接送一条SQL都 须要作两件事情：第一件事情是把咱们在relay log中记录的信息刷新到磁盘；另外一件事情就是更新他的工做日志——master.info，而且确保更新在磁盘上保存下来。若是我在到达slave前走 丢了，那master.info的最新记录会是排在我前面的一位兄弟，这样I/O线程在下一次接送的时候会从新接我到slave。可是特殊状况下，我可能 会被复制两遍：假设我已经顺利到达slave，而且已经在relay log中登记，I/O线程正要更新master.info笔记时忽然断电了，个人此次到访就没有被记录到master.info中。停电恢复后，I/O线 程按照master.info中的记录获取接送信息，I/O线程会重复的把我从master带到slave上，从而致使relay log中有两条个人记录。可是无论怎样，重复总比走丢好，是吧？ 出于这个考虑，SQL线程也采用一样的工做方式：在带领我执行完毕之后，再更新relay-log.info中的记录。在出现故障或是稍做休息后SQL线程会从relay-log.info的最后一个记录位置恢复执行。