MySQL主從複制原理

為什麼要做主從複制

1. 在業務複雜的系統中，有這麼一個情景，有一句sql語句需要鎖表，導緻暫時不能使用讀的服務，那麼就很影響運作中的業務，使用主從複制，讓主庫負責寫，從庫負責讀，這樣，即使主庫出現了鎖表的情景，通過讀從庫也可以保證業務的正常運作。
2. 做資料的熱備，主庫當機後能夠及時替換主庫，保證業務可用性。
3. 架構的擴充。業務量越來越大，I/O通路頻率過高，單機無法滿足，此時做多庫的存儲，降低磁盤I/O通路的頻率，提高單個機器的I/O性能。

MySQL主從複制的流程

1. 主庫db的更新事件(update、insert、delete)被寫到binlog
2. 主庫建立一個binlog dump thread，把binlog的内容發送到從庫
3. 從庫啟動并發起連接配接，連接配接到主庫
4. 從庫啟動之後，建立一個I/O線程，讀取主庫傳過來的binlog内容并寫入到relay log
5. 從庫啟動之後，建立一個SQL線程，從relay log裡面讀取内容，從Exec_Master_Log_Pos位置開始執行讀取到的更新事件，将更新内容寫入到slave的db

注：上述流程為相對流程，并非絕對流程

MySQL主從複制的原理

MySQL主從複制是一個異步的複制過程，主庫發送更新事件到從庫，從庫讀取更新記錄，并執行更新記錄，使得從庫的内容與主庫保持一緻。

binlog：binary log，主庫中儲存所有更新事件日志的二進制檔案。

binlog

是資料庫服務啟動的一刻起，儲存資料庫所有變更記錄（資料庫結構和内容）的檔案。在主庫中，隻要有更新事件出現，就會被依次地寫入到

binlog

中，之後會推送到從庫中作為從庫進行複制的資料源。

binlog輸出線程：每當有從庫連接配接到主庫的時候，主庫都會建立一個線程然後發送binlog内容到從庫。 對于每一個即将發送給從庫的sql事件，binlog輸出線程會将其鎖住。一旦該事件被線程讀取完之後，該鎖會被釋放，即使在該事件完全發送到從庫的時候，該鎖也會被釋放。

在從庫中，當複制開始時，從庫就會建立從庫I/O線程和從庫的SQL線程進行複制處理。

從庫I/O線程：當START SLAVE語句在從庫開始執行之後，從庫建立一個I/O線程，該線程連接配接到主庫并請求主庫發送binlog裡面的更新記錄到從庫上。 從庫I/O線程讀取主庫的binlog輸出線程發送的更新并拷貝這些更新到本地檔案，其中包括relay log檔案。

從庫的SQL線程：從庫建立一個SQL線程，這個線程讀取從庫I/O線程寫到relay log的更新事件并執行。

綜上所述，可知：

對于每一個主從複制的連接配接，都有三個線程。擁有多個從庫的主庫為每一個連接配接到主庫的從庫建立一個binlog輸出線程，每一個從庫都有它自己的I/O線程和SQL線程。

從庫通過建立兩個獨立的線程，使得在進行複制時，從庫的讀和寫進行了分離。是以，即使負責執行的線程運作較慢，負責讀取更新語句的線程并不會是以變得緩慢。比如說，如果從庫有一段時間沒運作了，當它在此啟動的時候，盡管它的SQL線程執行比較慢，它的I/O線程可以快速地從主庫裡讀取所有的binlog内容。這樣一來，即使從庫在SQL線程執行完所有讀取到的語句前停止運作了，I/O線程也至少完全讀取了所有的内容，并将其安全地備份在從庫本地的relay log，随時準備在從庫下一次啟動的時候執行語句。

參考：https://www.hoohack.me/2017/07/11/learning-mysql-replication-detail