2021年10月22日数据库备份踩坑记录
10 月 22 号下午，一条 UPDATE 少写了 WHERE。
发生了什么
那张表是系统配置，400 多行，存的是各门店的参数。本来只想改一行的值，语句粘到客户端里执行，回车之后看提示：Rows matched: 417 Changed: 417。手一下子凉了。
好在是配置表，不是订单。页面当时就开始不对劲，几个门店的参数全变默认值，客服群里先冒出两条消息。
恢复那两小时
没备份，这是最要命的。最后是从 binlog 里把这批 UPDATE 反推出来，按 position 导出成反向 SQL，再跑回去。两个人核对了 40 分钟，把 417 行逐条比对，改回 400 多行里真正该保留的值，中间有 12 行本来就打算改，得单独挑出来。
前后两小时。页面恢复之前，我们在群里发了一句「在处理，别下单」，比默默修着强。
事后加的三样
- 主从复制。一台从库，读写分离先不做，纯粹为了有个能立刻切过去的副本。延迟盯着，超过 5 秒告警。
- 每天凌晨 3 点全量备份，binlog 单独存，保留 7 天。备份完自动往一张表写一行校验记录，光看脚本退出码不算数，得能查到备份文件大小和行数。
- 所有 UPDATE 和 DELETE 走一个包装脚本，执行前先打印预计影响行数，要人敲一次确认。生产库的直连客户端收掉了，只留只读账号给日常查。
一条没写进文档的规矩
误删那位没挨骂。会上只说了一句：谁都会手滑，所以别让人有手滑的机会。
后来我们评审 SQL 时多问一句「这条没带条件会怎样」，问了半年，成了习惯。有回一个新同事写完语句自己先愣了一下，把 WHERE 补上了，没人提醒他。
那 417 行的截图还留在内部文档里，标题是《两小时》。
