概述
MySQL內核為讀寫分離的實現提供了支持,包括通過系統variable設置目標節點,session或者是事務的只讀屬性,等待/檢查指定的事務是否已經Apply到只讀節點上,以及事務狀態的實時動態跟蹤等的能力。
今天主要分享下mysql內核對讀寫分離的支持特性,以下基于mysql5.7版本。
只讀屬性--read_only
如需設置節點為只讀狀態,將該read_only參數設置為1或TRUE,但設置 read_only=1 狀態有幾個需要注意的地方:
- read_only=1只讀模式,不會影響slave同步復制的功能,所以在MySQL slave庫中設定了read_only=1后,通過 show slave statusG 命令查看salve狀態,可以看到salve仍然會讀取master上的日志,并且在slave庫中應用日志,保證主從數據庫同步一致
- read_only=1只讀模式,可以限定普通用戶進行數據修改的操作,但不會限定具有super權限的用戶的數據修改操作
- 臨時表的操作不受限制
- log表(mysql.general_log和mysql.slow_log)的插入不受影響
- Performance Schema表的update,例如update和truncate操作
- ANALYZE TABLE或者OPTIMIZE TABLE語句 為了讓所有的用戶都不能進行讀寫操作,MySQL 5.6就需要執行給所有的表加讀鎖的命令 flush tables with read lockG,這樣使用具有super權限的用戶登錄數據庫,想要發生數據變化的操作時,也會提示表被鎖定不能修改的報錯,同時,slave的同步復制也會受到影響。
只讀屬性--super_read_only
在5.7之后,可以通過設置這個variable, 使得具有super權限的用戶也不能對數據做修改操作,而不必通過flush tables with read locKG的方式了。
把super_read_only設置成on, read_only會隱式的被設置成on;反過來,把read_only設置成off,super_read_only就會隱式的被設置成off。
只讀屬性--tx_read_only
如果這個variable設置為ON,事務的訪問模式就變成了只讀,不能對表做更新,但對臨時表的更新操作仍然是允許的。
設置只讀事務在引擎層可以走優化過的邏輯,相比讀寫事務的開銷更小,例如不用分配事務id,不用分配回滾段,不用維護到全局事務鏈表中。
讀一致性保證
讀寫節點之間的數據通常是有gap的,如果有辦法知道在主節點上的執行的事務已經被復制到了只讀節點,對這(些)事務敏感的讀操作就可以被路由到只讀節點上,這就是“讀一致性”。
MySQL 5.6 引入了GTID (GTID 實際上 是由 UUID+TID 組成的。其中 UUID 是一個 MySQL 實例的唯一標識。TID 代表了該實例上已經提交的事務數量,并且隨著事務提交單調遞增。),提升了MySQL節點復制的功能。
圖:基于GTID的主從復制
MySQL 5.6提供了WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(GTID_SET[,TIMEOUT])函數來等待從節點把GTID_SET指定事務都執行完畢,除非timeout(以秒為單位)的時間已經耗費而超時。 這個方法存在一些缺點,例如:
- 該功能依賴于slave來運行,如果復制線程沒有啟動或者出錯了,就會返回錯誤。在某些情況下我們需要一直等待;
- 返回的是執行的事件的個數,這通常是沒有意義的,返回成功或者失敗即可。
MySQL 5.7為解決上面的幾個問題,又添加了新的函數 WAIT_FOR_EXECUTED_GTID_SET(GTID_SET[,TIMEOUT])。當GTID_SUBSET(GTID_SET, @@global.gtid_executed)成立時,即指定的GTID是gtid_executed的子集時,返回0表示成功,否則返回1,表示失敗,如果超時,也會失敗。
總結
讀寫分離是MySQL實現負載均衡,保證高可用和高擴展性的重要手段,MySQL內核提供了對讀寫分離的多種手段的支持,從通過設置系統variable在事務,session,以及節點級別設置只讀屬性,到通過使用GTID和WAIT_FOR_EXECUTED_GTID_SET函數,都可以保證只讀節點與主幾點的讀一致性。