全程回放：100T核心数据库升级历险记

另外一个是在投产前的32小时,发生了一个大的事务在运行.没有人能评估出这个事务还有多少时间可以结束,那怎么办?只能当机立断去kill这个事务.这个事务当时产生了很多的回滚,回滚是需要时间的,根据当时的速度需要98个小时,但离升级还只有32小时,根本来不及.我们整个准备了半年的升级一年就只有这么一次,如果错过了,就相当于今年的升级就要告吹了,而以后也仍按照3T的速度来增长,也不太可能再做这个升级.这也是我为什么60个小时不睡觉的原因.升级部门到了总部,告诉我,必须等到事务回滚完才能升级,因为采用的是本地升级.他没给出什么方法,我这边无论是调回滚的定期发布,还是调一次回滚的安全数,在别的数据库里面都是有效的,但对这个数据库完全没效.

最后我发现它主要的问题出在db file sequential read上,怎么办?发现它在回滚的过程中有一个materialized view log,而这个materialized view log所有数据文件只在一个存储卷里.在这一个卷上我想到用FLASH闪存去替换这一个存储卷,但这需要冒很大风险,和第一个我刚刚提到的存储同步故障是有关联的,第一个已引发了生产故障,然后这个又要在这个生产环境上去做存储同步,这甚至是冒着被炒鱿鱼的风险,我没有告诉其他人,自己做的这个决策.我觉得做领导就该这样,你只要勇敢做,并敢于承担.

所以,将物化视图所在的文件卷替换成Flash闪存,加快db file sequential read的效率后,最终发现回滚速率提升了5倍.同时连夜把一些存储的同事从凌晨三点钟叫到公司,启用存储Cache预热功能,将物化视图和物化视图log缓存到内存中,发现回滚速率又提升了3倍.终于赶在升级前的6个小时,回滚完毕,来得及去做升级这个动作.

4、投产运行分析

最终在投产后,所幸实施过程是非常顺利的.在投产后,高峰期业务吞吐量整整提升了大概25%,批量作业效率提升了5-25倍不等,系统前端响应时间平均提升30%以上,单个SQL效率提升5-9000倍不等.主机的CPU运行从升级前的60%,有时业务高峰甚至达到70-80%,现在升级后CPU运行在20-30%左右.整个效果看起来还是非常好的.

小结

通过本次升级我想说的是,这里面用到的一些思想和方法,其中包括一些敏捷运维的思想,是可以借鉴到以后同类数据库产品的升级,也可以用到其他的如主机、存储等领域的变更或更新换代.这就是我全部的分享,希望能对大家有所启发.

文章来自微信公众号：DBAplus社群

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!