GreatSQL社区

搜索

【MySQL 5.7 停服讨论区】如何应对 MySQL 5.7 EOL?

673 10 2023-10-30 17:03
2023 年 10 月底,MySQL 5.7 走到了其生命周期的终点(EOL),这意味着 MySQL 官方社区将不再修复任何 bug 或更新安全补丁。如果升级到更高的 MySQL 8.0 版本,可以得到官方更新支持,算是一个简单直接的应对方案。

但不久的将来,MySQL 8.0 也 EOL 了,该如何处理呢?我们是否有其他选择?是否可以寻找一个更完美的、不受掣肘的替代方案呢?

为此,GreatSQL 社区专门开设 MySQL5.7 停服讨论区,关于停服的各类问题,欢迎大家在此畅所欲言,吐露心声,也可以听听其他人的观点或看法,给自己带来一些启发价值。

话题讨论内容包括但不限于:
您如何看待 MySQL 5.7 停服这一事件?
面对 5.7 停服,您是否在当前 5.7 数据库的使用上碰到了困难,
都面临哪些困难和风险,未来打算怎么做?
如果您是业内技术大咖,是否可以给 5.7 用户们一些专业、实用的建议?

欢迎在本帖下回复内容 & 参与投票,我们为大家准备了活动奖励,内容点赞数高的小伙伴有机会获得数据库书籍《高性能 MySQL(第4版)》或社区定制双肩背包一个哦,快来参与讨论吧~


专区讨论时间:点赞数统计截止:2023.12.31 24:00

活动奖励:

  • 投票 & 参与讨论者(回复内容 20 字以上):社区金币 100 个;
  • 投票 & 精华回复(回复内容 100 字以上):社区金币 300 个;
  • 投票 & 回复内容获赞数前五名(点赞数需≥ 5个):第一名《高性能 MySQL(第4版)》一本;第二、三名社区双肩包一个;第四、五名社区定制鼠标垫一个。

双肩包红.png

多选投票: ( 最多可选 3 项 ), 共有 12 人参与投票
您所在的用户组没有投票权限
全部回复(10)
ShawnYan 2023-10-31 00:42:14
本帖最后由 ShawnYan 于 2023-10-31 00:44 编辑

MySQL 8.2 来了,8.4 LTS 还会远么

MySQL 5.7 继续使用也可以,除非遇到crash之类的严重bug,不然也不会进行升级。

至于 MySQL 8.0 还是算了,版本管理混乱,普通人根本分不清哪个版本稳定,只能盲目选择最新的 8.0.35。

或者,选择兼容的国产数据库,比如,GreatSQL, GBase, TiDB, OB 等等。

renduy 2023-10-31 09:58:55
5.7的存量应该还是巨大的,毕竟这个版本前些年是最普遍的版本。如何应对?
上策:升级到MySQL 8.0。好处还是多多的,性能、功能、工具都有很大提升,这里就不展开了。
中策:升级8.0还是有点点技术门槛的,尤其是使用了复杂存储过程或者自定义函数的,还得改造业务。这种情况下,花点钱,延续MySQL 5.7的支持也是一种办法。可以与MySQL的供应商或社区联系,了解是否可以获得继续支持该版本的服务。某些供应商可能会提供针对旧版本的延期支持合同或服务计划。
下册:切换其他的数据库。一些常见的替代选项包括PostgreSQL、Oracle和Microsoft SQL Server。在切换到其他数据库之前,请进行充分的评估,并确保业务需求与替代方案相匹配。
vvvvvv 2023-10-31 15:44:34
1.  对于已有并且稳定运行的业务,只要不碰到bug,数据库不会轻易去给他升级;
2. 对于开发未上线上线的业务,可以挑选一个稳定版,一般来说就最新的了;
3. 确实需要升级的,可以考虑升级到8.0,8.2暂时还不考虑
4. 如果考虑到信创要求,可以使用国产数据库,grestsql
5. 还有个原则,单机能解决的,就不用分布式,量实在太大,单机撑不住了会考虑国产分布式,tidb、ob等。
铎铎是只猫 2023-11-1 08:51:06
本帖最后由 铎铎是只猫 于 2023-11-1 09:01 编辑

MySQL5.7这个版本相当经典,而且用户数应该也是最多了,最佳实践和资料也最多,如果是已经使用中的数据库,那我觉得不是遇到特别严重的bug或者新需求依赖新版本功能的话没有升级的动力。8.0某些版本不是太稳定,和5.7也差异巨大,对于运维来说升级毕竟吃力不讨好,见过不少因为升级带来的事故,如果不是领导强推的话能稳定运维就别动了,据我了解还不少公司5.5也还在跑着呢。8.0的某些新功能其实很好用,新的不是特别重要的业务倒是可以考虑试试8.0先练练手,或者也可以考虑考虑国产数据库,这几年国产数据库发展很快,尤其是数据量比较大的时候更有优势。
chongzh 2023-11-1 22:45:39
停服,不是服务器“停了”,而是指产品生命周期终止(EOL)。也就是说2023年10月21号以后不管出了什么问题,都不会再有来自社区官方的补丁升级,但是咱们可以选择GreatSQL呀。GreatSQL完全免费并100%兼容MySQL,对于正在使用MySQL5.7版本客户,可以完全平滑、免费过渡到GreatSQL5.7、GreatSQL8.0,从而获得GreatSQL社区持续支持与维护,规避“停服”风险。
喜欢就关注我公众号:DBA烂笔头
dbms 2023-11-3 09:12:44
5.7EOL只是没有官方支持了,使用没啥问题可以不升级;oracle11g不是也停很久了,使用11g的还有很多,甚至还有少数9i,10g的古董,稳定是王道,等8.4长期版本再考虑升级的事吧;
当然也可以考虑更换其他数据库,比如greatsql,PG等等;如果迁移到greatsql相对其他的数据库来讲风险是最小的;
haozixu 2023-11-6 11:20:10
从DBA角度来说需要升级,但是从业务角度来说,现在业务跑得没啥问题,也没有遇到啥隐形的BUG,性能也满足需求,为啥要升级,万一升级了系统不稳定,甚至造成事故,这个锅谁来背,所以很多业务就不想升级
王权富贵 2023-11-8 10:28:46
迁移到最新版本的 MySQL
MySQL 5.7已经结束生命周期,因此建议将数据库迁移到最新版本,以获得更好的性能、安全性和新功能。可以使用 MySQL 8.0 或更高版本,这些版本提供了更好的兼容性和更多的功能。在迁移之前,请确保备份数据,并测试新版本以确认应用程序的兼容性。

如果不想升级到新版本的 MySQL,可以考虑购买商业支持。

如果不想购买商业支持,可以使用 GreatSQL
忆雨林枫 2023-11-8 16:21:31
本帖最后由 忆雨林枫 于 2023-11-8 16:32 编辑

先回答话题中的几个问题
您如何看待 MySQL 5.7 停服这一事件? -- 不影响现在的业务
面对 5.7 停服,您是否在当前 5.7 数据库的使用上碰到了困难,
都面临哪些困难和风险,未来打算怎么做? -- 技术困难暂时没有遇到, 业务困难-目前使用了多个小版本,后期根据实际业务情况做合并或者升级
如果您是业内技术大咖,是否可以给 5.7 用户们一些专业、实用的建议?-- 在满足业务的前提下,稳定是王道,但是要学习新版本的知识,储备足够的知识且能支撑你职业未来5年。

个人随心言:
上面很多人的回帖,都或多或少的囊括了当前国内的各种状态。
从公司业务角度上讲:正在使用的版本,一般都能满足业务当前或者未来一两年的发展需求,所以更倾向于追求稳定,不轻易变更现有的版本。除非遇到搞不定的bug,但是领导应该 还是倾向于小版本变动,毕竟,升级到8,涉及很多方面,尤其是应用代码。

从个人职业发展上讲:毕竟8已经出来很久了, 如果不去学习,对于一个职业DBA那就有点说不过去了。而且后面个人跳槽,肯定更多的是会面临8的问题,至少在面试的时候会被问及5.7和8之间的区别。
所以作为个人职业发展,我的建议是公司的新项目上推荐直接上8,这样就有了自己学习和验证的动力及环境,积累实战经验。
对于正在运行的业务,可以尝试向上反馈,并给出自己的意见和建议,主动去推动公司的数据库全面升级,记得是主动。好处如下:
1.公司的技术面得到升级 ---这对于公司对外宣传的时候也是一个亮点。
2.丰富提升自己的技术经验 ---这里面的经验包括:数据库跨版本,服务器资源整合和数据库资源整合,业务线路梳理,全面的安全隐患排查及修复。
3.提升自己的综合素质 ---主动推动这项工作,需要全面协调,领导、开发、测试、产品、运营等等上下游各方面,这会提升你个人的组织能力,协调能力,沟通能力以及执行能力。
4.提升业绩(升职加薪) ---做好充足的测试和验证以及故障回滚方案,极大可能的降低这些工作的失败率,确保成功推动升级,并成功完成升级,个人的年度绩效必须是最大的亮点,也是最大的加分项。同时通过整个项目,得到每个人的认可,实至名归。


在具备优秀的技术前提下,还要主动承担相应的责任,主动做出成绩,你就是最靓的仔!
职场也是江湖,不单是各个命令,还有人情世故。
不要安于现状,除非家里有矿。
版本不断的在更新,我们的技术也要进步,
时代在快速发展,时间流逝的也很快,想想去年这个时候,我们都还戴着口罩。

奋斗吧! 少年!
12下一页
admin

39

主题

4

博客

123

贡献

管理员

Rank: 9Rank: 9Rank: 9

积分
200

勤学好问(铜)写作分享(铜)助人为乐(铜)给予赞同(铜)炙手可热(银)

合作电话:010-64087828

社区邮箱:greatsql@greatdb.com

社区公众号
群助手
QQ群
GMT+8, 2023-12-6 03:20 , Processed in 0.025133 second(s), 20 queries , Redis On.
快速回复 返回顶部 返回列表