记一次数据库“脑裂“问题的复盘

Posted 2021-07-08 鱼翔空

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了记一次数据库“脑裂“问题的复盘相关的知识，希望对你有一定的参考价值。

问题回顾

4月2日开发发现专有云的用户rds实例链接数报警，并于中午发起了数据库配置变更申请；
4月8日14:00 某云在场运维巡检，发现该实例有中断的任务，尝试补偿执行失败；
4月8日14:23 某云在场运维直接手动操作跳过一些步骤，将中断任务继续执行；
4月8日17:30，许久没消息的报警群，突然收到一堆报警，用户系统提示：com.mysql.jdbc.exceptions.jdbc4.CommunicationsException，其他系统提示调用用户系统Read timed out，后续又报Connection refused
4月8日17:35 开发在堡垒机上尝试连接数据库，发现无法telnet通
4月8日17:36 上升到DBA，发现该实例在已经不存在；
4月8日17:40 上升到某云，在场运维排查后无法解决；
4月8日17:50 开始呼叫总部支持；
4月8日18:00 发现rds对应的vip后续无挂载实例；
4月8日18:05 通过元数据发现对应的主实例；
尝试通过应用程序挂载主实例，多次尝试失败；
4月8日18:25 某云内部沟通，让运维直接手动操作，挂载成功；
4月8日18:29 数据库连接恢复，应用恢复正常；
4月8日18:35 验证整体流程没问题；
4月9日10:00 安排开发对数据进行抽样排查；
4月9日10:15 测试发现从库从4月8日14:23 后无同步记录（堡垒机无主库操作权限）；
4月9日10:30 开发通过调用链随机抽取数据发现当时注册成功但数据库无数据；
4月9日10:45 开发通过后台接口查验，发现数据库无数据（后台）；
4月9日10:50 申请堡垒机主库访问权限；
4月9日11:00 确认主库4月8日18:30之前无数据；
4月9日11:10 让开发查询小于4月8日最后一条数据，发现数据时间为4月2日12:11;
4月9日11:15 安排开发开发登录/注册拦截功能，并批量将问题用户缓存删除；
4月9日11:20 让DBA操作用户关键表结构，将主键+100万的操作；
4月9日12:00 DBA无法通过脚本+100w修改数据库自增主键；
4月9日12:20 让DBA对关键表进行insert数据，并指定主键操作；
4月9日12:30 DBA将所有的数据同步任务停止，批量完成主键修改；
4月9日13:00 将区间用户4月2日至4月9日所有的新用户导出；
4月9日14:00 讨论影响范围以及具体方案；
4月9日14:30 某云来现场复盘该问题，并制定后续方案；
4月9日15:00 上线第一版拦截；
4月9日15:33 发现用户数据库链接数过多，无法链接；
4月9日15:40 查看监控发现数据库监控指标除了链接数，其他无问题；
4月9日15:45 DBA和现场运维尝试修改数据库链接数，修改几次失败；
4月9日15:50 已无数据进行；
4月9日15:52 发现项目初始化链接过多，安排开发将初始化链接降到10/20，最大降到50/100;
4月9日15:55 链接数据库发现大量的慢sql，基于主键的查询也几百秒了；
4月9日16:00 kill一批大于2秒的sql，发现还慢，执行explain发现explain都得执行十来秒，初步怀疑磁盘有问题；
4月9日16:05 再次无法连接；
4月9日16:10 让驻场运维开始kill 慢sql，同时询问有无办法进行漂移；
4月9日16:20 偶然听到旁边一运维哥们说了一句备份的事，并确认复盘完了怕现有实例有问题，进行一次全量备份；
4月9日16:25 停止掉全量备份，业务恢复；
4月9日17:00 监测到还有漏网用户进来；
4月9日18:00 开发修改代码上线，彻底堵住；