一次mysql数据库备份还原导致的生产环境事故

事故直接原因

pv dengqimes_20250519_144357.sql | mysql --database=dengqimes-test --user=zy_mes -pr4UQBwBV --host=127.0.0.1 --port=3306  --default-character-set=utf8mb4

使用 pv | mysql的组合，老版mysql在shell命令处理参数时，会忽略 dengqimes-test 中的 -，导致实际上mysql将备份还原到了数据库 dengqimes 上。而正式环境和测试环境数据库名恰好仅用-加后缀进行区分。

• “pv | myslq 版本演示”

事故间接原因

1. 正式环境和测试环境数据库名不是使用下划线区分或直接加后缀，而是使用-，而短线在linux shell脚本中常常导致参数解析问题
2. 正式环境和测试环境数据库的用户名、密码完全一致，如果密码不一样命令不会执行成功
3. 正式环境和测试环境数据库部署在同一台服务器上
4. 没有开启binlog，没有二进制文件没法恢复

事后处理

事后开发这边做的：

1. 尝试恢复数据库，mysql无binlog日志，恢复失败。由于是丢失的下午的数据，数据库每日备份也没有用；
2. 修改测试环境数据库密码
3. 部分设备运行状态为停机处理
4. 从工艺实时监测值表、操作日志表，手动恢复部分工单产量数据
5. （TODO）需找时机再配置开启binlog，因为需要重启mysql服务器

杜绝此类事故再发生

1. 正式环境和测试环境数据库密码一定要保证不同
2. 正式环境和测试环境前期就最好分开部署，彼此之间不会互相影响
3. MySQL要开启binlog日志，数据丢失才能做数据恢复
4. 像是整个还原数据库到测试环境这种操作要慎重再慎重，最好找客户不操作的时候，执行之前做一次全量备份
5. 这种配合第三方APS的要求进行还原数据库的行为，能找理由拒绝就拒绝，能手动导入的就手动导入。
6. 对生产环境每一个命令、脚本等操作都要慎重，心怀敬畏。能在客户端UI界面操作的就在客户端操作。