美文网首页
MySql表的主键超限导致的生产事故

MySql表的主键超限导致的生产事故

作者: Running的程序员 | 来源:发表于2022-10-10 23:10 被阅读0次

    前两天系统的一张明细表的主键字段超出了限制范围,引发了一次生产事故。由于是底层服务使用的表,导致公司多个业务线系统无法使用,属于比较重大的生产事故,分享给大家,避免出现此类低级又重大的生产问题。

    奋力写bug.png

    事故反馈

    首先反馈出异常的是服务的告警机制,告警群中出现大量MySQL异常告警:


    告警群.png

    然后一线业务使用方在工作群中反馈系统不可用,然后我们赶快紧急排查并解决问题。你懂的,在你排查解决问题的过程中各个相关的同事都会过来问候你一下:产品经理、上级领导、运营、其它服务调用方....此时,你面不改色,镇定自若,其实内心(手动狗头)...

    事故原因

    导致此次线上事故的原因是系统的一张老表(很早的一张表)的主键是int类型,表中数据存储的数据量(行数)达到了int值的上限:2147483647。你可以想象到这个表有多大:上百GB!
    你可能会觉得这种问题好low啊!你说还债也好,报应也罢,我们就当一次日后吹牛逼的话题吧。针对此次事故,重要的是我们解决问题的过程以及从中获取的经验

    解决方案

    方案1
    删除表中的旧数据,设置表的主键自增从0开始,此方案沟通后不行。原因:

    1. 生产数据不能随便删除,可能有未知隐患
    2. 表中数据量太大,这张表日增数据量近百万级,从几百G的大表中删除百万数据(需够一天使用),这个操作将会消耗大量的数据库实例的资源,进而影响其它业务,不可接受

    方案2
    把表的主键类型由int改为bigint,对应的代码model由Integer改为Long。此处可能是大家有些着急吧,犯了一个流程性的问题:我们开发认为代码层面方案没问题,在热火朝天的修改,结果表结构的变更工单提交给DBA审批,不通过,表数据量太大,变更表结构极其耗时,可能小时级,方案废弃

    方案3
    创建一张新表,结构和原表一样(只是把主键类型换为bigint),主键自增从2300000000开始(为了和旧表数据区分),修改业务代码:

    1. 代码中,新数据写入到新建的表中
    2. 代码中查数据,从新表和老表中一起查询,合并返回。之所以新旧表一起查询,是因为事故发生时有的业务已经产生过明细数据,然后又被业务人员重新操作,新数据存在新表中

    最终采用此方案,修复上线,问题解决。

    方案后续处理

    1. 后续将旧表的数据同步到新表中,恢复单表查询
    2. 表数据归档

    复盘反思

    1. 数据库表的主键建议采用bigint类型(一般性规约,除非是简单的配置表用int)
    2. 对老系统,可以定期巡查相关数据表(有告警最好),提早发现遗留问题,提前解决
    3. 处理紧急问题,思路很重要,不能盲目修改

    相关文章

      网友评论

          本文标题:MySql表的主键超限导致的生产事故

          本文链接:https://www.haomeiwen.com/subject/qxttzrtx.html