2019年，SonarQube和Gitlab相继宣布不再提供对MySQL方式存储数据的支持，技术选型就是这样，有人选有人放。选择不提供支持，自然会对既往的用户提供了升级的障碍，即使这样他们也要放弃支持，由于官方发文中都有对于放弃原因的解释，通过这篇文章我们来驻足观望一下。

SonarQube：End of Life of MySQL Support

sonarqube安装教程mysql sonarqube不支持mysql_PostgreSQL

2019年4月10号，SonarQube发文称在7.9之后，所有的SonarQube的版本（CE、DE、EE和DCE）中将停止对MySQL的支持。我们知道SonarQube本身提供了一个演示的H2的数据库，同时支持对于MySQL、Postgresql、Oracle等主流数据库的支持。

在发文之前，SonarQube对使用SonarQube LTS 6.7.x的版本，采取如下两个步骤：

首先，停止了DCE的MySQL支持

其次，建议所有的商业环境中使用PostgreSQL，尤其是当需要很多实例同时运行或者可能会随着时间的推移变得越来越大的场景。 根据社区反馈的问题的情况，放弃MySQL的举措使得用户相关的部署问题大幅度的降低。

不再支持MySQL的原因非常直接，性能，或者说扩展而导致的性能问题。放弃MySQL的结论来源于如下的团队的共识和思考：

  • 随着规模的扩大，SonarQube应该能够给用户以良好的性能体验。
  • SonarQube 7.x的发布，横向扩展和运行速度都得到了增强，但是数据库性能需要进一步提高。
  • 团队需要集中主要力量完成性能提高的挑战，而对于使用MySQL完成这一挑战对团队来说比较困难。
  • 为了更好地聚焦于产品自身，决定放弃对于MySQL的支持，从而使得SonarQube能提供更好的一致性的用户体验。

SonarSource希望他们的用户能够在数据量逐渐增大的情况下仍然具有很好的操作感受，显然放弃MySQL就是他们的答案。数据量的增大和横向扩展想的要求带来了挑战，SonarQube团队希望集中力量解决，他们决定聚焦于PostgreSQL来进行完善。他们认为这项决定从长远来看将会有很好的效果，经过深思熟虑决定作出这个将会给用户升级带来数据迁移的决定。考虑到迁移会花费一定的精力，所以特地提供了一个迁移的工具来进行辅助。 从SonarQube 7.9开始，支持的数据库变为：Oracle、Microsoft SQL Server和PostgreSQL。Oracle和SQL Server是收费的商业数据库而PostgreSQL则是开源免费的。SonarQube聚焦于提供资源对PostgreSQL进行支持，以保证用户在使用免费数据库的基础上也能够获得同等的良好体验。 而对于有人提出的MySQL仍然是使用的非常广泛的数据库的质疑，给予的回答就是scale，显然SonarQube认为使用MySQL无法达到这一结果，或者是在他们的团队中无法实现。

Gitlab: Why we’re ending support for MySQL in 12.1

sonarqube安装教程mysql sonarqube不支持mysql_PostgreSQL_02

对于Gitlab来说，他们也认为不再支持MySQL不是一个容易的决定。在2019年6月27日，Gitlab宣布从12.1版开始不再支持MySQL。而且有一个issue记录了他们的心路历程，非常有趣。

  • https://gitlab.com/gitlab-org/gitlab-foss/issues/51173#issues 摘录一段非技术因素如下所示，更加详细的内容可以参看上述链接

Figure out how many paying customers we have that use MySQL, and how much we earn from this. Having 500 customers use it but pay us €5 wouldn’t really be worth the effort of supporting MySQL. On the other hand, 2 customers paying €500 000 is a different story.

同样Gitlab原本也是支持PostgreSQL和MySQL的，现在决定完全放弃MySQL。在他们的解释中并没有说MySQL不好，而是说在他们的使用场景下有很多限制，比如：

  • 无法使用MySQL高性能地支持内置的group
  • 不得不使用非正规途径增加列的限制，而这些又导致了MySQL无法正常存储数据
  • MySQL无法添加不指定长度的TEXT类型的列
  • MySQL不支持局部索引
  • MySQL不支持Geo

除此之外，如下面引用所描述的那样，还增加了维护的成本，拖慢了迭代的速度。

Creating and maintaining this code is a drain on our cycle time and velocity, and it puts a dampener on our value of iteration.

持续集成系统的测试因为MySQL的存在也需要多跑一遍，Gitlab团队认为只是因为一小部分的MySQL用户而进行这样的成本投入是很难有说服力的。

PostgreSQL有些特性MySQL不支持，在两种数据库同时存在的时候很难平衡。比如希望使用PostgreSQL的LATERAL JOIN对仪表板数据进行优化，却因为MySQL不支持而没有办法付诸实施。

根据Gitlab所掌握的搜集到的数据，据说他们的大部分主要顾客已经迁移到PostgreSQL上了。而这些数据给他们了信心在12.1之后放弃MySQL。当然他们也给出了数据迁移的辅助解决方案。

总结

工具没有最好的，最适合的那个才重要。SonarQube和Gitlab在开源的DevOps工具链的生态中是比较重要的存在，他们放弃MySQL是一个信号，还仅仅是个例，这个可能要取决与MySQL自身特性与功能的改善和更新，让我们拭目以待。

参考内容

https://community.sonarsource.com/t/end-of-life-of-mysql-support/8667 https://about.gitlab.com/blog/2019/06/27/removing-mysql-support/ https://gitlab.com/gitlab-org/gitlab-foss/issues/49583