前言

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 工程师的博客上听过了这个设计构想，当时就觉得非常棒，可行度很高，官方现在在工程上实现了。这是一个伟大的设计。

• 自动创建不可见主键，关键点在于"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。

以上表格总结自《深入浅出MGR专栏文章》，食用 MGR 的指南，建议阅读后享受 MGR。

参考:

https://gitee.com/GreatSQL/GreatSQL-Doc#%E4%B8%93%E6%A0%8F%E6%96%87%E7%AB%A0