AWS EC2上MongoDB社区版无故被清空 故障原因排查咨询

MongoDB 社区版不存在任何内置的、会自动触发全库重置/清空的默认配置，官方所有发行版本的默认运行逻辑下，不会对用户存储的数据执行任何自动删除操作。结合你在EC2上的部署场景，按出现概率从高到低，数据莫名清空的可能原因如下：

• 公网暴露引发的恶意扫库攻击
  这是EC2上部署MongoDB最常见的丢库原因。如果你的EC2安全组将MongoDB默认27017端口对0.0.0.0/0开放，且未配置账号密码鉴权，互联网上的自动化恶意扫描脚本会快速发现该开放端口，自动执行全库删除操作，部分脚本还会留下要求支付赎金恢复数据的占位数据库。即便开启了鉴权，如果使用弱密码，也可能被暴力破解后执行删库操作。
• 存储挂载异常导致的“假清空”
  如果MongoDB数据存储在独立EBS卷上，当EC2实例意外重启、EBS卷挂载失败时，MongoDB进程会自动使用启动参数指定的默认空路径（通常是系统盘下的临时空目录）作为dbpath启动。此时应用连接到MongoDB后，看到的就是完全无数据的空实例，表现和数据库被清空完全一致。
• Spring Boot配置误触发数据删除
  即便业务代码未编写删除逻辑，也需要排查两类配置问题：
  • 生产环境启动配置中是否残留带dropDatabase()逻辑的初始化脚本（比如之前测试阶段编写的数据库初始化命令，被配置为启动时自动执行）
  • 是否错误引入嵌入式MongoDB相关依赖，导致应用启动时没有连接到远程生产库，反而拉起本地临时MongoDB实例；当应用重启或临时实例进程退出时，就会表现为“生产库数据全部丢失”
• 副本集/定时任务配置异常
  如果你曾测试配置过MongoDB副本集，后续操作中如果错误将空数据节点提升为副本集主节点、原数据节点被移出副本集，应用连接到新主节点时，就会看到所有原有数据库消失的情况。另外如果服务器cron、MongoDB内置定时任务中残留了全库删除逻辑，到触发时间点也会自动清空所有数据。

• 检查MongoDB启动日志，确认当前进程实际加载的dbpath路径，核对是否和之前存放数据的路径一致
• 检查MongoDB访问日志，查看是否有来自陌生IP的dropDatabase操作记录
• 核对EC2安全组的27017端口访问规则，确认是否存在对公网开放的配置

内容的提问来源于stack exchange，提问作者Puneri Pagadi