GreatSQL 8.0.27 & 5.7.36背后的事

开个番外，在正式的change log之外，单开一篇介绍下GreatSQL 8.0.27-18（晚些时候发布，还在努力合并中）和5.7.36-39两个新版本的一些幕后故事吧。

1. 为什么要推出GreatSQL 5.7

GreatSQL主打的特性就是针对MGR做了众多提升和改进，另外就是8.0相对5.7其MGR的功能及可靠性也会好很多，因此本来是不想推出GreatSQL 5.7的。

但考虑到目前5.7版本还有大量的用户，可能还不便于升级到8.0，为了让这些用户也能体验更好的MGR，才决定也新增5.7分支，主要是针对MGR的稳定性、可靠性及性能等方面做了些提升和优化，尤其是大事务的优化，但在8.0里的新特性都没有，因此还是强烈建议尽早升级到8.0版本，以体验更好更可靠的MGR。

2. GreatSQL 5.7针对大事务场景做了什么优化

鉴于此，GreatSQL 5.7.36主要是提升MGR的可靠性、稳定性及性能，尤其是针对大事务场景下的可靠性。

在MySQL 5.7中，MGR事务没有进行分片处理，执行大事务很容易造成超时（并反复重发事务数据），最终导致节点报错并退出集群，甚至会造成mysqld进程被oom kill。

在GreatSQL 5.7中，针对该问题进行优化，并设置事务上限约为150MB，超过该上限事务会失败回滚，但节点不会再退出集群。虽然会对应用造成一定程度的不便，但总好过节点报错退出甚至crash吧。

3. 为什么要引入MGR网络开销超时记录功能

在MGR结构中，一个事务的开销包含网络层以及本地资源（例如CPU、磁盘I/O等）开销，GreatSQL针对MGR的网络层开销进行了多项优化工作，因此在网络层的开销通常不会成为瓶颈。

当事务响应较慢想要分析性能瓶颈时，可以先确定是网络层的开销还是本地性能瓶颈导致的。通过设置选项 group_replication_request_time_threshold 即可记录超过阈值的事件，便于进一步分析。

这个特性对于排查性能问题帮助较大，所以在5.7和8.0中都引入了。

4. 关于仲裁节点MGR很容易被"诟病"的地方是，一个MGR集群通常至少配置3个节点，相对于两节点主从架构来说，的确是增加了服务器成本。

引入仲裁节点功能后，这个苦恼几乎不复存在了，因为仲裁节点所需要的资源非常低，其主要功能是参与MGR投票仲裁，无需存储用户数据以及binlog，开销非常小，因此完全可以在一台服务器上跑多个实例作为仲裁节点，这就非常划算了。

此外，引入这个新功能后，官方的mysql shell很多功能都用不了，需要修改源码，加入对仲裁节点角色的支持。情急之下，仅凭我的三脚猫工夫，居然成功修改mysql shell源码，增加了对仲裁节点的支持。不过之后编译环境倒是折腾了好几天才解决，这些过程已在文章mysql-shell for GreatSQL 8.0.27编译安装及使用里分享了。

5. MySQL官方发版不太严谨

在ARM & CentOS 7环境下编译MySQL 5.7时遇到一个报错：

error:'prctl' was not declared in this scope

需要手动把 prctl.h 头文件copy到MySQL源码目录下，再修改 mysqld.cc 文件，加入include才行。这个问题可参考华为云官网上的这篇文章：error:'prctl' was not declared in this scope。

另外，在编译mysql shell 8.0.27时，发现 CMakeLists.txt 文件中少了一个宏定义，也需要自己手动修改加入才行。MySQL官方对待我报的bug(#106730)时，态度也略显傲慢。。。

有种个人感受，自从MySQL归入Oracle旗下后，虽然也增加了不少优秀的新特性，但引入的新问题也挺多的，官方基本不care来自社区的反馈声音，这其实挺符合Larry的人设的。。。

先扯这么多，在国内搞开源不易，肯定大家多使用GreatSQL和提建议、反馈问题，这就是对我们最大的支持了。