我是一条数据更改操作，来自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的最后一个记录位置恢复执行。
这就是我从master到slave的全部见闻啦，如果你还有更多想要知道的细节，请回复本文，我会给你回信的O(∩_∩)O