MySQL 主備的基本原理

MySQL 主備切換流程.png

主備同步流程圖

備庫 B 跟主庫 A 之間維持了一個長連接。主庫 A 內部有一個線程，專門用于服務備庫 B 的這個長連接。

一個事務日志同步的完整過程是這樣的：

在備庫 B 上通過 change master 命令，設置主庫 A 的 IP、端口、用戶名、密碼，以及要從哪個位置開始請求 binlog，這個位置包含文件名和日志偏移量。

在備庫 B 上執行 start slave 命令，這時候備庫會啟動兩個線程，就是圖中的 io_thread 和 sql_thread。其中 io_thread 負責與主庫建立連接。

主庫 A 校驗完用戶名、密碼后，開始按照備庫 B 傳過來的位置，從本地讀取 binlog，發給 B。

備庫 B 拿到 binlog 后，寫到本地文件，稱為中轉日志(relay log)。

sql_thread 讀取中轉日志，解析出日志里的命令，并執行。

binlog 三種格式

1. Row

日志中會記錄成每一行數據被修改的形式，然后在 slave 端再對相同的數據進行修改。

優點：在 row 模式下，bin-log 中可以不記錄執行的 SQL 語句的上下文相關的信息，僅僅只需要記錄那一條記錄被修改了，修改成什么樣了。所以 row 的日志內容會非常清楚的記錄下每一行數據修改的細節，非常容易理解。而且不會出現某些特定情況下的存儲過程或 function ，以及 trigger 的調用和觸發無法被正確復制的問題。

缺點：在 row 模式下，所有的執行的語句當記錄到日志中的時候，都將以每行記錄的修改來記錄，這樣可能會產生大量的日志內容，比如有這樣一條 update 語句：

UPDATE product SET owner_member_id = 'b' WHERE owner_member_id = 'a'

執行之后，日志中記錄的不是這條 update 語句所對應的事件 (MySQL 以事件的形式來記錄 bin-log 日志) ，而是這條語句所更新的每一條記錄的變化情況，這樣就記錄成很多條記錄被更新的很多個事件。自然，bin-log 日志的量就會很大。尤其是當執行 alter table 之類的語句的時候，產生的日志量是驚人的。因為 MySQL 對于 alter table 之類的表結構變更語句的處理方式是整個表的每一條記錄都需要變動，實際上就是重建了整個表。那么該表的每一條記錄都會被記錄到日志中。

2. Statement

每一條會修改數據的 SQL 都會記錄到 master 的 bin-log 中。slave 在復制的時候 SQL 進程會解析成和原來 master 端執行過的相同的 SQL 再次執行。

優點：在 statement 模式下，首先就是解決了 row 模式的缺點，不需要記錄每一行數據的變化，減少了 bin-log 日志量，節省 I/O 以及存儲資源，提高性能。因為他只需要記錄在 master 上所執行的語句的細節，以及執行語句時候的上下文的信息。

缺點：在 statement 模式下，由于他是記錄的執行語句，所以，為了讓這些語句在 slave 端也能正確執行，那么他還必須記錄每條語句在執行的時候的一些相關信息，也就是上下文信息，以保證所有語句在 slave 端杯執行的時候能夠得到和在 master 端執行時候相同的結果。另外就是，由于 MySQL 現在發展比較快，很多的新功能不斷的加入，使 MySQL 的復制遇到了不小的挑戰，自然復制的時候涉及到越復雜的內容，bug 也就越容易出現。在 statement 中，目前已經發現的就有不少情況會造成 MySQL 的復制出現問題，主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現，比如：sleep() 函數在有些版本中就不能被正確復制，在存儲過程中使用了 last_insert_id() 函數，可能會使 slave 和 master 上得到不一致的 id 等等。由于 row 是基于每一行來記錄的變化，所以不會出現類似的問題。

3. Mixed

從 5.1.8 版本開始，MySQL 提供了除 Statement 和 Row 之外的第三種復制模式：Mixed，實際上就是前兩種模式的結合。

在 Mixed 模式下，MySQL 會根據執行的每一條具體的 SQL 語句來區分對待記錄的日志形式，也就是在 statement 和 row 之間選擇一種。

新版本中的 statment 還是和以前一樣，僅僅記錄執行的語句。而新版本的 MySQL 中對 row 模式也被做了優化，并不是所有的修改都會以 row 模式來記錄，比如遇到表結構變更的時候就會以 statement 模式來記錄，如果 SQL 語句確實就是 update 或者 delete 等修改數據的語句，那么還是會記錄所有行的變更。

循環復制問題

通過上面對 MySQL 中 binlog 基本內容的理解，你現在可以知道，binlog 的特性確保了在備庫執行相同的 binlog，可以得到與主庫相同的狀態。

因此，我們可以認為正常情況下主備的數據是一致的。也就是說，圖 1 中 A、B 兩個節點的內容是一致的。其實，圖 1 中我畫的是 M-S 結構，但實際生產上使用比較多的是雙 M 結構，也就是圖 9 所示的主備切換流程。

MySQL 主備切換流程 -- 雙 M 結構.png

對比圖 9 和圖 1，你可以發現，雙 M 結構和 M-S 結構，其實區別只是多了一條線，即：節點 A 和 B 之間總是互為主備關系。這樣在切換的時候就不用再修改主備關系。但是，雙 M 結構還有一個問題需要解決。

業務邏輯在節點 A 上更新了一條語句，然后再把生成的 binlog 發給節點 B，節點 B 執行完這條更新語句后也會生成 binlog。(我建議你把參數 log_slave_updates 設置為 on，表示備庫執行 relay log 后生成 binlog)。

那么，如果節點 A 同時是節點 B 的備庫，相當于又把節點 B 新生成的 binlog 拿過來執行了一次，然后節點 A 和 B 間，會不斷地循環執行這個更新語句，也就是循環復制了。這個要怎么解決呢？

從上面的圖 6中可以看到，MySQL 在 binlog 中記錄了這個命令第一次執行時所在實例的 server id。因此，我們可以用下面的邏輯，來解決兩個節點間的循環復制的問題：

規定兩個庫的 server id 必須不同，如果相同，則它們之間不能設定為主備關系；

一個備庫接到 binlog 并在重放的過程中，生成與原 binlog 的 server id 相同的新的 binlog；

每個庫在收到從自己的主庫發過來的日志后，先判斷 server id，如果跟自己的相同，表示這個日志是自己生成的，就直接丟棄這個日志。

總結

以上是生活随笔為你收集整理的mysql 主从一致性_mysql 主从一致性保证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。