一條命令帶你體驗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的最後一個記錄位置恢復執行。