MySQL _主備基本原理

MySQL 主備基本原理

學習檢測

1. 主從流程？

學習總結

1. 主庫事務提交，寫入binlog 日誌，從庫有IO線程和主庫建立長連接，接收二進制文件存到relay log，備庫SQL線程負責將relay log 的內容複製到從庫中
   
   在狀態 1 中，客戶端的讀寫都直接訪問節點 A，而節點 B 是 A 的備庫，只是將 A 的更新都同步過來，到本地執行。這樣可以保持節點 B 和 A 的數據是相同的。

當需要切換的時候，就切成狀態 2。這時候客戶端讀寫訪問的都是節點 B，而節點 A 是 B 的備庫。

在狀態 1 中，雖然節點 B 沒有被直接訪問，但是我依然建議你把節點 B（也就是備庫）設置成只讀（readonly）模式。這樣做，有以下幾個考慮：

• 有時候一些運行類的查詢語句會被放到從庫上去查，設置爲只讀可以有效的防止誤操作
• 防止切換邏輯有bug，比如切換過程中出現雙寫，造成主備不一致
• 可以使用readonly狀態，來判斷節點的角色

你可能會問，我把備庫設置成只讀了，還怎麼跟主庫保持同步更新呢？

這個問題，你不用擔心。因爲 readonly 設置對超級 (super) 權限用戶是無效的，而用於同步更新的線程，就擁有超級權限。

接下來，我們再看看節點 A 到 B 這條線的內部流程是什麼樣的。圖 2 中畫出的就是一個 update 語句在節點 A 執行，然後同步到節點 B 的完整流程圖。

備庫 B 跟主庫 A 之間維持了一個長連接。主庫 A 內部有一個線程，專門用於服務備庫 B 的這個長連接。一個事務日誌同步的完整過程是這樣的：

1. 在備庫B上通過change master命令，設置主庫的A的IP、端口、用戶名、密碼、以及要從那個位置開始請求binlog，這個位置包含文件名和日誌偏移量
2. 在備庫B上執行start slave命令，這時候備庫會啓動兩個線程，就是圖中的io_thraed和sql_thread，其中io_thread負責與主庫建立連接
3. 主庫 A 校驗完用戶名、密碼後，開始按照備庫 B 傳過來的位置，從本地讀取 binlog，發給 B。
4. 備庫 B 拿到 binlog 後，寫到本地文件，稱爲中轉日誌（relay log）。
5. sql_thread 讀取中轉日誌，解析出日誌裏的命令，並執行。

這裏需要說明，後來由於多線程複製方案的引入，sql_thread 演化成爲了多個線程，跟我們今天要介紹的原理沒有直接關係，暫且不展開。

binlog

學習檢測

1. binlog 的三種形式及優缺點？

總結

1. 三種模式
   • statement 記錄的是執行語句（原始sql語句），日誌量小
   • row 記錄的是數據修改前和後的值，日誌量大
     • binlog_row_image 爲FULL會記錄所有的字段，minimal是記錄必要的字段
       • 常用作數據的恢復
         • mixed 是statement 和row的結合