本文讲述了作者在处理线上数据更新时遭遇的两次回滚事故。第一次事故由于接口参数传递错误和关联数据未备份导致数据恢复困难；第二次事故因忽视部分数据不应更新，再次触发回滚。作者总结了教训，包括代码逻辑清晰、尊重线上数据、预验证、备份重要性等，并提出全表数据备份的建议。
来自公众号：新世界杂货铺
程序猿最大的悲哀是什么！
经历了这两次事故后，笔者觉得最大的悲哀莫过于半夜打电话给DBA请求帮忙恢复数据。程序猿和PM之间的战斗往往还有来有回，而笔者碰上DBA之后，那可真是求人办事，怎么怂怎么来，只要DBA大爷高兴！
为了以后尽量少跪舔DBA大爷，笔者将亲身经历的两次事故记录下来以提醒自己。
第一次数据回滚
PM是需求的生产者，程序猿是需求的消费者，这二者就是典型的生产者与消费者模型。因此本次事故的根因还是PM提出了需求，故笔者认为只要PM不再提需求就不再有事故。
唉！快醒醒，别做梦了！
回到事故的本身，笔者先描述一下当时的背景。
PM有大量的数据需要紧急更新到线上。这需求有多紧急呢？PM要绕过QA验证，直接在线上先用少量数据进行测试，少量数据验证通过后就更新所有剩余的数据。
结合笔者所在公司的业务场景，笔者按照以下步骤完成了本次数据更新。
1、将需要更新的数据使用mysqldump进行备份。
mysqldump --replace -f --single-transaction -t \
-h 
最低0.47元/天 解锁文章
扫一扫
8858
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
