Redian新闻
>
聊聊即将到来的MySQL5.7停服事件

聊聊即将到来的MySQL5.7停服事件

公众号新闻
上个月,信通院下属的云计算开源产业联盟发布了一个关于MySQL数据库开源生态的研究报告《开源数据库生态发展研究报告-MySQL开源数据库》,其中提到了在10月份MySQL社区将会发生一件大事--MySQL 5.7将会于2023年10月21日结束服务期(EOL)。

MySQL目前已经成为中国用户使用最广泛的开源数据库,其中5.7版本的用户的比重又是最高的,因此MySQL 5.7 EOL事件会影响到很多MySQL用户。
         
根据报告中的统计数字,MySQL 5.7用户占比在国内高达47%。届时这些用户将会面临选择,如何应对EOL事件。实际上2020年的时候就有一些机构提醒用户,MySQL 5.7按照生命周期将于2023年到达服务期限,当时这件事还在MySQL社区和DBA圈子里引发过一些关于开源项目安全性的讨论。3年后,这个狼来了的问题,终于正式要面对我们了。
         
实际上数据库EOL的问题并不是在MySQL 5.7上第一次出现,Oracle用户都很清楚每个版本EOL的时间表。只不过Oracle官方依然会对付费用户提供延长期服务,还会在数年时间里继续为这些用户发布安全补丁包,因此EOL的Oracle版本依然可以通过各种渠道找到安全补丁包。而作为开源数据库的MySQL,EOL就意味着开源社区不再提供安全与功能方面的补丁升级了。
面对MySQL 5.7 EOL这个事件,percona官方宣布了付费支持的计划,在EOL之后的三年内,percona会为需要服务的客户提供收费服务支持。不过支持的力度如何,是否承诺对安全问题发布补丁不得而知。
MariaDB一贯的对MySQL持有敌意,他们希望MySQL 5.7用户不要升级MySQL 8了,而是通过11条简单的命令迁移到MariaDB上去。除此之外,一些云厂商也纷纷提出了解决方案。
云厂商则纷纷发布了延长服务的声明,微软Azure将会在MySQL 5.7 EOL之后,为其公有云用户提供延长的服务,由Azure官方提供支持,最晚到2025年。
类似情况,亚马逊也将为其公有云用户提供一年期的支持。不论是亚马逊还是微软,当延长服务期结束后,MySQL 5.7用户将必须强制升级到MySQL 8或者迁移到其他数据库上。

面对这个问题,国内的MySQL生态的数据库厂商也纷纷给出了自己的迁移方案,希望吸引这部分用户到自己的产品上来。
         
面对MySQL 5.7 EOL这个事件,我们会如何面对呢?最近我也和一些MySQL 5.7用户做了一些交流,根据他们反馈的情况,以及业内对此问题的应对措施,再结合报告中反馈的四种情况,我总结了一下,大致有六种应对措施。
         
第一条路径:直接升级到8.0。做出此选择的MySQL5.7用户占比较高,此类用户对此问题早已了解,并且在半年前就已经开始应对工作。MySQL 5.7升级到8.0不仅仅是更换一个数据库版本而已,因为8.0与5.7在技术上有较大的差异,CBO优化器与SQL引擎都有一定的不同,因此数据库升级后应用需要做全面的测试,对于不够兼容的部分代码做一定的修改才能确保顺利迁移。因此采用第一种路径的用户,需要做一定的提前准备。
         
第二条路径:直接迁移到MySQL兼容的国产数据库。有一部分客户考虑到信创的问题,原本就已经计划对数据库进行国产化替代,准备一次性到位。如果用国产数据库替代,那么可以选择的路径也很多,很多国产数据库产品就是MySQL生态产品,比如腾讯TDSQL、万里GreatSQL、中兴通讯GoldenDB、Oceanbase、阿里PolarDB-x等。如果不需要使用存储过程,还可以考虑TiDB。很多国产数据库也有MySQL兼容模式,虽然不能完全兼容MySQL,应用做少量的修改也可以迁移过去。达梦、人大金仓、GaussDB等数据库都有MySQL兼容模式。直接迁移到国产数据库的优点是从根本上完成数据库国产化替代,不过缺点也很明显,一方面是迁移需要一定的资金,也需要一定的时间,另外一方面是国产数据库许可证采购的总体成本不低。
         
第三条路径:迁移到其他MySQL生开源产品,比如MariaDB和国内的GreatSQL。向MariaDB迁移的用户主要考虑的是摆脱Oracle生态,选择一个相对更加安全的开源项目,不过MariaDB社区是否足够安全,也是仁者见仁智者见智。GreatSQL是Percona Server的一个开源分支,也基于GPLV2协议,代码托管在国内的gitee上。在保持与Percona Server兼容的基础上,会更快速地修复漏洞,保障用户的数据安全。随后GreatSQL开源社区将会在官网上开设一个MySQL5.7停服专区,帮助MySQL 5.7的用户解决一些服带来的问题,为某些暂时无法升级的用户提供支撑随着软件供应链安全方面的需求的不断加强,国内开源项目分支的发展将会迎来高速发展。这条路径的迁移成本较低,缺点是用户目前对国内的开源分支的认可度还存在一定问题。
         
第四条路径:对于公有云用户,依托云平台再多撑一两年,在一两年中再选择方向。公有云厂商还会对MySQL 5.7提供一定时间的延长支持。公有云用户先观望一年再选择稳妥的技术路线的比例是比较高的。这条路线获得了一定时间的缓冲区,以便于做出更为科学的决策,不过仅仅是过渡期的临时做法。
         
第五条路径:换门,从MySQL直接更换数据库种类,转投另外一个开源数据库 PG 阵营。和摄影界换门一样,采取这条路径是要下大决心的。因为以往的应用都要修改,数据都要迁移,以往积累的应用开发与运维经验也都要放弃。
         
第六条路径:不变,继续使用MySQL 5.7。数据库都是在内部使用的,因此把网络的安全边界扎牢,哪怕有安全漏洞,也不升级,不改变,等到应用系统升级的时候再考虑升级或者更换数据库。选择这条路线的用户比例不低,这条路径成本最低,不过要承担一定的安全风险。采用这条路线的用户把安全依托在网络安全和边界安全上,通过扎紧篱笆来防止安全事故。
         
最后要表达的观点是,EOL是很多产品都会面临的事件,无需过度担心。不过数据库产品的EOL影响面更广一些,处理起来也更麻烦一些,特别是MySQL 5.7,对于一些复杂一些的系统,直接升级到8.0还是需要做一些验证工作的。作为一个核心的数据资产承载体,没有安全补丁处于裸奔状态的数据库也是一个比较大的隐患。从软件供应链安全上看,商用数据库Oracle在代码上的安全性要高于MySQL这样的开源数据库,再加上Oracle延长期服务依然在出安全补丁,用户也可以通过一些特殊渠道获得安全补丁。因此相对于Oracle数据库的版本EOL,MySQL 的EOL问题更受企业级用户的重视。面对即将到来的MySQL 5.7 EOL,IT部门的领导和DBA哪怕没有做什么动作,多思考一下也是好的。

《开源数据库生态发展研究报告-MySQL开源数据库》有兴趣的朋友可以点击文后的阅读原文去下载。  
         
         
         
         

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。
相关阅读
如何设计一款基于 MySQL 实现的 Message Queue莫扎特:第四十一交响曲基于MySQL多通道主主复制的机房容灾方案MySQL 调整版本控制模型,发布首个创新版本 8.1.0MySQL数据导入方案推荐技术同学必会的MySQL设计规约,都是惨痛的教训MySQL到底是 join 性能好,还是in一下更快呢?MySQL binlog 三个典型的业务应用场景阿里终面:10亿数据如何快速插入MySQL?Mysql集群之PXC-Docker安装花园维修戏题回乡散记三DoltgreSQL发布,基于Git的PostgreSQL生产环境遇到MySQL数据页损坏问题如何解决?MySQL中update“经典”的坑,这样写语句,直接劝退!“MySQL 之父”的 MariaDB 要完蛋了?叫停两款核心产品并裁员 28%【尘封档案】系列之185:“华东八室”之513特务案(一)MYSQL事务的底层原理4 种 MySQL 同步 ES 方案,yyds!VLDB顶会论文解读 | PolarDB MySQL高性能强一致集群核心技术详解为何在中国MySQL远比PostgreSQL流行Nginx 代理 MySQL 连接,并限制可访问 IPMySQL备份恢复最佳实践:终极指南红色日记 4.1-8MySQL 8.2 正式可用,支持读写分离Python如何使用MySQL 8.2读写分离?MySQL到TiDB:Hive Metastore横向扩展之路弃用 MySQL 后存储成本降低 85%,携程业务系统数据库升级技术实践基于 MySQL 多通道主主复制的机房容灾方案“MySQL 之父”的 MariaDB 要完蛋了?叫停两款核心产品并裁员 28%,分析师:该行为无异于自毁长城重磅 |《开源数据库生态发展研究报告》发布 GreatSQL为MySQL5.7最佳替代方案!SQL骚操作,一条SQL 统计近 7天、30天、全部的订单量一网打尽总结 Mysql 的所有 BufferMySQL 分库分表实践MySQL如何性能调优?上篇
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。