分布式数据库处于发展期,还未达到成熟期,使用过程中遇到的各类问题较多,需要及时修复,但是现在普片数据库厂商版本迭代太快,对厂商来说可以更好及时修复问题,进行功能优化。但是没有考虑到用户的实际情况,如果升级频繁可能对原有系统带来风险和问题,现在市场上OB、TDSQL、TIDB等等分布式数据库都有这个问题,而且维护人员还需要重新进行一次熟悉和安全检测。用户如果自己选择时间进行升级,跨多版本进行升级,跨度太大,这样对各个版本前后兼容问题会带来很大风险,而且有的还必须让厂商来做,这里边还会涉及行内配合费用,厂商的人天也很贵的,对用户来说是升级也不是,不升级也不是的困境。
针对眼下分布式数据库版本的迭代频率,大家如何考虑?对大家来说真的好吗?大家在分布式数据库版本迭代上是如何处理的,如何应对版本频繁升级?希望大家在投票后可以谈谈自己企业的应对经验!
对于各种产品的版本迭代,真的是件矛盾的事情。产品研发上线的周期短。缺少充足的测试时间导致产品本身有很多bug,加上各种业务需求不断更新导致产品不断的额更新。但是数据库是整个业务的核心。多数情况下,企业都难以承受数据库版本更新所可能产生的各种风险而选择维持现状,但时间一久。又会加加大产品本身带来问题的风险。
面对现在不断更新的版本。虽然明知道过快的版本迭代不好。但其实还是要正面这个问题。选择一个折中的周期来进行版本的更新。既不要过于频繁的更新数据库版本而增加风险和运维压力。也不要长时间的不更新,等到喝市场主流版本脱节而导致更新成本激增,甚至到无法解决的地步
对于银行业来说,每年的软件基线的固定的,所以不希望软件频繁更新。对于所有类型业务系统来说,数据库的稳定更是大家看中的。接受正常有计划的版本迭代,不希望迭代太快。
收起版本迭代升级需要大量的回归性测试工作,会引起业务停机时间变长及增加相关人员工作内容及协调难度。整体的运维成本其实是挺高的,应定期评估软件bug影响程度,对于重大的bug要及时升级 ,对于有其他变通做法的bug 不做升级,让应用开发商尽可能修改。每年做一次升级评估,定期升级 ,保持数据库版本在行业主流版本的范围内。
收起目前tidb是火车头发布 每月一个版本,我们最早上的是4.2 现在他们发布到6.1了 我们测试也升到6.1,生产环境一般不能升级,升级需要停库升级,这个太要命了。如果有问题就只能通过备份恢复数据库 从备份做全恢复的话 停机时间太长接受不了,所以我们用TIDB,只能在底层硬件替换的时候会换大版本升级,测试环境啥的都是可以及时更新的。
收起