MySQL 8.0.30,一個值得上車MGR的版本

語言: CN / TW / HK

前言

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 個流行的架構不靠譜,我一個一個來說。

  1. keepalived + 主從/雙主架構,由於是雙機自仲裁架構,自己既是運動員跑資料庫,自己也是裁判仲裁資料庫,肯定會出大問題的。有可能出現最後大家都認為自己是 master 的時候,大家都持有 VIP,這就是所謂的腦裂現象。

  2. 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 語言寫的,勸退了很多人。

  3. 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