MySQL 8.0.30,一個值得上車MGR的版本
前言
MySQL 8.0.30,這個版本沒有 MGR 方面的重大修改,為什麼我說值得上車 MGR 呢?
GIPK
只因為 8.0.30 新增了 sql_generate_invisible_primary_key
引數,以下我簡稱為 GIPK 模式!
GIPK 模式下,建立表時如果沒有顯式定義主鍵會自動新增一個不可見主鍵索引,請參考以下兩張表:
## sql_generate_invisible_primary_key=off 建的表 mysql> SHOW CREATE TABLE auto_0\G *************************** 1. row *************************** Table: auto_0 Create Table: CREATE TABLE `auto_0` ( `c1` varchar(50) DEFAULT NULL, `c2` int DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 1 row in set (0.00 sec) ## sql_generate_invisible_primary_key=on 建的表 mysql> SHOW CREATE TABLE auto_1\G *************************** 1. row *************************** Table: auto_1 Create Table: CREATE TABLE `auto_1` ( `my_row_id` bigint unsigned NOT NULL AUTO_INCREMENT /*!80023 INVISIBLE */, `c1` varchar(50) DEFAULT NULL, `c2` int DEFAULT NULL, PRIMARY KEY (`my_row_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci 1 row in set (0.00 sec)
在官方沒有設計這個功能之前,我早在 percona 工程師的部落格上聽過了這個設計構想,當時就覺得非常棒,可行度很高,官方現在在工程上實現了(老葉備註:實際上,阿里雲RDS很早就實現了類似的功能)。這是一個偉大的設計。
-
自動建立不可見主鍵,關鍵點在於"INVISIBLE" 關鍵字,那麼
select * from xxx
出來的結果和之前是相容的,不會多出來my_row_id
列。 -
如果表本身有主鍵,那麼 GIPK 就不會自動建立主鍵
-
如果建表時沒有顯式指定主鍵,建表時請勿包含列名叫
my_row_id
的列,因為 GIPK 模式自動建立的不可見主鍵列固定就叫做my_row_id
,會有衝突導致建立表失敗 -
GIPK 功能只在新建表時觸發,如果表已經建了並且沒有主鍵,請自行解決或重建表
他解決了大家卡住很多人上車 MGR 的一個硬性要求,表必須要有主鍵!
實際上,沒有主鍵在主從架構甚至單機架構也是不建議的,現在 GIPK 這個特性可以讓那些懶惰的開發再也無法阻攔 MGR 的崛起。
8.0.30 MGR 上車吧!
高可用架構
MySQL 活了那麼久一直沒有一個靠譜的高可用架構方案,所有的高可用架構都是第三方提供的,主流的例如 keepalived + 主從/雙主架構、MHA 架構、orchestrator 架構,一直到 5.7.17 才出來第一個官方的高可用架構 MGR。
為什麼我說前面那 3 個流行的架構不靠譜,我一個一個來說。
-
keepalived + 主從/雙主架構,由於是雙機自仲裁架構,自己既是運動員跑資料庫,自己也是裁判仲裁資料庫,肯定會出大問題的。有可能出現最後大家都認為自己是 master 的時候,大家都持有 VIP,這就是所謂的腦裂現象。
-
MHA 架構,一般是三臺主機,A、B、C三臺機器,假設 A 是 master,B 是 slave,C 可以部署 slave 也可以不部署,假設 C 上不部署 MySQL,C 只做仲裁,也就是 C 仲裁 A、B,仲裁員是同一個人 C,這種情況腦裂風險就很低了。所以 MHA 比 keepalived 架構是靠譜很多的,並且 MHA 還支援第二仲裁鏈路的配置。但 MHA 已經至少 4 年半沒有更新過程式碼了,作者從未在 MySQL8.0 上宣稱支援,所以我強烈不建議 MHA 用於 MySQL8.0,除非你有二次開發 MHA 架構的能力。MHA 的仲裁節點本身不是高可用的會有單點的問題,這也是一個讓人小不爽的地方。MHA 有 gtid 下,主庫掛了但主庫主機沒掛的情況不會 binlog 補數的 bug,這個只能通過半同步規避,這個有能力的同學可自行修復程式碼。但他的程式碼是 perl 語言寫的,勸退了很多人。
-
orchestrator 本來是明日之星,但 2021 年 7 月開始作者表示隱退,可以說這個專案已經處於半黃的狀態了,他是比 MHA 要優秀很多的架構,用 go 語言編寫,有能力的同學可以考慮二次開發之後食用,但沒有二開能力的同學食用他可能挺痛苦,反正我測出來好多 bug,我沒能力改程式碼。
再來看 MGR,官方開發,能保證可靠穩定,不存在作者跑路現象,並且 MGR 是採用 paxso 仲裁的演算法,三機架構就是三個節點投票,獲得兩票的可以選為主,一般正常使用不會腦裂。
MGR5.7 可以上車嗎?
MySQL8.0 的 MGR 相對與 MySQL5.7 的 MGR 有以下優勢,所以 MGR 對於 5.7 版本是不合適的。
以上表格沒有花很多心思總結,實際上應該會有更多的對比項證明 5.7 不適合 MGR。重點是最後一個,導致 5.7 根本上車不了 MGR(老葉備註:如果非要在5.7版本上車MGR,強烈建議選擇GreatSQL 5.7.36-39版本,相對於MySQL官方社群版有挺多改進和提升)。
以上表格總結自《 深入淺出MGR 》 專欄文章 ,食用 MGR 的指南,建議閱讀後享受 MGR。
參考:
http://gitee.com/GreatSQL/GreatSQL-Doc#%E4%B8%93%E6%A0%8F%E6%96%87%E7%AB%A0
全文完。
《 深 入 淺 出 M G R 》 視 頻 課 程
戳 此 小 程 序 即 可 直 達 B 站
http://www.bilibili.com/medialist/play/1363850082?business=space_collection&business_id=343928&desc=0
文 章 推 薦 :
想 看 更 多 技 術 好 文 , 點 個 “ 在 看 ” 吧 !
- 無損半同步複製下,主從切換後資料一致嗎?
- MySQL 8.0.30,一個值得上車MGR的版本
- RC隔離級別下,死鎖案例分析
- MySQL 8.0新的GTID持久化執行緒和GTID恢復方式
- 淺析MySQL死鎖檢測
- MySQL記憶體為什麼不斷增高,怎麼讓它釋放
- MySQL 啟停過程瞭解一二
- 技術分享 | 微服務架構的資料庫為什麼喜歡分庫分表?
- MySQL記憶體管理機制淺析
- 深入淺出MySQL 8.0錯誤日誌
- MySQL Update執行流程解讀
- MySQL複製主從例項表DDL不一致導致失敗案例
- Linux環境監控工具彙總
- MySQL 8.0 BACKUP LOCK淺析及其在xtrabackup的應用(深度好文)
- 建議收藏|MySQL DBA 防坑指南
- 利用sysbench執行測試
- GreatSQL 8.0.27 & 5.7.36背後的事
- MySQL8.0快速回收膨脹的UNDO表空間
- 通過DML語句淺談binlog和redo log
- MacOS下編譯percona及部分函式的運算差異