线上数据被回滚两次我都做了哪些不正确的操作

在数据库实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《线上数据被回滚两次我都做了哪些不正确的操作》，聊聊MySQL、后端，希望可以帮助到正在努力赚钱的你。

来自公众号：新世界杂货铺

程序猿最大的悲哀是什么！

经历了这两次事故后，笔者觉得最大的悲哀莫过于半夜打电话给DBA请求帮忙恢复数据。程序猿和PM之间的战斗往往还有来有回，而笔者碰上DBA之后，那可真是求人办事，怎么怂怎么来，只要DBA大爷高兴！

为了以后尽量少跪舔DBA大爷，笔者将亲身经历的两次事故记录下来以提醒自己。

第一次数据回滚

PM是需求的生产者，程序猿是需求的消费者，这二者就是典型的生产者与消费者模型。因此本次事故的根因还是PM提出了需求，故笔者认为只要PM不再提需求就不再有事故。

唉！快醒醒，别做梦了！

回到事故的本身，笔者先描述一下当时的背景。

PM有大量的数据需要紧急更新到线上。这需求有多紧急呢？PM要绕过QA验证，直接在线上先用少量数据进行测试，少量数据验证通过后就更新所有剩余的数据。

结合笔者所在公司的业务场景，笔者按照以下步骤完成了本次数据更新。

1、将需要更新的数据使用

mysqldump --replace -f --single-transaction -t \
-h hostname -u user -P 3936 -p dbname tablename  \
--where="id in (1,2,3)"  > tablename.sql

2、开发一个脚本直接调用线上已有更新数据的接口（开发时笔者已经在测试环境自测）。

3、在线上先更新少量数据，并更新修改数据部分的缓存，PM对少量数据进行验证。

4、PM确认该部分数据验证通过后，开始对剩余数据进行线上更新操作。

初看上面的步骤好像没什么大问题，但实际结果却是狠狠地打了笔者的脸。下面，笔者就好好掰扯掰扯到底是哪些原因造成了本次事故。

1、更新接口

alter table table_a rename to table_a_bk_2;
alter table table_a_bk rename to table_a;

好家伙，DBA暗示已经这么明显了嘛，笔者二话不说默默地发了一封邮件准备申请一个具有DDL权限的账号。笔者现在想的十分清楚，以后再有这种批量更新线上数据的操作一定好好全表备份数据而不是使用仅有读权限的账号备份

-- 全表备份sql语句
CREATE TABLE table_a_bk AS SELECT * FROM table_a;

总结

下面是这两次事故发生后笔者的一些心得，希望可以给大家提供参考。

1、代码逻辑要清楚，函数参数命名要语义清晰。一个参数就包含了所有需要的数据是十分不正确的行为同时代码中尽可能多些注释。

2、对线上数据充满敬畏，操作数据时要理清楚业务逻辑。

3、准备操作线上数据前，尽量先在无缓存环境下进行数据预验证。

4、人都有可能会犯错，所以还需要QA进行双重保证。

5、笔者就是吃了紧急需求的亏才导致这两次事故，其他情况请务必按照正常流程进行数据操作。

6、备份真的很重要！这两次事故后笔者认为前文提到的全表数据备份方案相对合理且易恢复。

最后，衷心希望本文能够对各位读者有一定的帮助

今天带大家了解了MySQL、后端的相关知识，希望对你有所帮助；关于数据库的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~