2019年9月3号上午 12 点，误删了线上数据库。1点左右使用当天凌晨 00:30 的数据库备份恢复，丢失了 00:30 到 1 点之间的数据。
"蝴蝶效应"，"明知山有虎偏向虎山行"
起因是这个时间段对项目进行了重写，需要数据迁移。本来是有测试库的，但由于一些问题，测试库无法使用（灾难的伏笔），因此在线上 mongod 建立了测试库。这意味着线上数据库与测试数据库都在一起（灾难的前奏）。我在进行迁移测试的时候，对测试库使用了一个和线上库很相近的名字 (灾难的预兆)。我在测试完成以后，想要删除测试库，误把线上库当成了测试库 (灾难的发生) 删除了。
- 凡是可能出错的事就一定会出错 (墨菲定律)。
- 无论什么情况下，都不要把测试库和线上数据库放在一起。
- 加前缀 vs 加后缀： winner 加前缀。
- 数据库的重要操作例如删除数据库的权限一定要收缩。
- 如果两个东西有必要进行区分那就一定要非常不同
- 数据库备份，尝试增量备份，尽量缩短备份时间，若要求 RPO 为零的情况下可以做 实时数据备份
- 已有服务提供商：各种数据库厂商，Dell EMC
- 专门的云服务
- 明确 恢复及时性（RTO） 以及 恢复时间点 （RPO） wiki 概念
- 开发人员在操作数据库是一次只能打开一个数据库连接
- 备份，备份，备份，RPO == 0 > RPO == N > RPO == 无限
2019年9月3号上午 12 点，误删了线上数据库。1点左右使用当天凌晨 00:30 的数据库备份恢复，丢失了 00:30 到 1 点之间的数据。
"蝴蝶效应"，"明知山有虎偏向虎山行"
起因是这个时间段对项目进行了重写，需要数据迁移。本来是有测试库的，但由于一些问题，测试库无法使用（灾难的伏笔），因此在线上 mongod 建立了测试库。这意味着线上数据库与测试数据库都在一起（灾难的前奏）。我在进行迁移测试的时候，对测试库使用了一个和线上库很相近的名字 (灾难的预兆)。我在测试完成以后，想要删除测试库，误把线上库当成了测试库 (灾难的发生) 删除了。