结合你描述的情况——非Docker环境运行正常，仅容器化后出现数据丢失，且和pythonscript容器报错强相关，我们可以从以下几个方向逐步排查：

1. 检查MongoDB容器的启动逻辑与数据卷权限 #

你的MongoDB Dockerfile里用了CMD docker-entrypoint.sh mongod，虽然这和官方镜像的默认行为一致，但有两个细节需要确认：

• 主机数据卷权限问题：挂载的./data:/data/db目录需要让容器内的mongodb用户（UID通常为999）拥有读写权限。如果权限不足，MongoDB启动时可能无法加载已有数据，甚至会自动初始化一个空数据库。你可以在主机上执行以下命令修复权限：

  sudo chown -R 999:999 ./data
  

• 数据卷类型的影响：你提到试过Docker内部存储仍有问题，但可以尝试用named volume替代主机卷再次验证，避免主机目录的潜在干扰：

  # 修改database服务的volumes配置
  volumes:
    - mongodb_data:/data/db
  # 在compose文件末尾添加named volume定义
  volumes:
    mongodb_data:
  

2. 深挖pythonscript报错与容器重启的连锁反应 #

虽然你明确说没有删除集合/数据库的代码，但Docker环境下的容器重启特性可能放大了脚本的异常影响：

• 检查异常处理逻辑：当脚本连接MongoDB失败（比如数据库容器重启未就绪）时，有没有可能在重试或异常分支里误执行了重置操作？比如非Docker环境下重试机制不会触发的代码，在容器反复重启后被意外执行？
• 跟踪完整日志：用docker logs -f pythonscript实时跟踪脚本日志，重点关注数据丢失前的执行步骤，确认报错前后是否有可疑的数据库操作。

3. 查看MongoDB容器的操作日志 #

数据被清空必然对应有操作记录，你可以通过MongoDB日志定位源头：

• 执行docker logs mongodb，搜索dropDatabase、dropCollection关键词，确认是否有明确的删除操作，判断是脚本触发还是其他原因。
• 如果日志中没有删除操作，大概率是数据卷未正常挂载，导致容器每次重启都使用临时存储。此时可以查看容器启动日志，是否有/data/db目录权限不足或挂载失败的报错。

4. 排查容器重启的触发条件 #

三个容器都设置了restart: always，需要关注重启的连锁影响：

• 如果MongoDB容器因内存不足被系统OOM Killer终止，重启时可能未完成数据同步，导致数据异常。你可以通过dmesg或Docker daemon日志确认是否有这类情况。
• 检查pythonscript重启时的初始化逻辑：脚本重启时会不会执行一些非Docker环境下不会触发的初始化操作，比如重新创建集合并清空数据？

5. 验证MongoDB镜像的初始化脚本 #

你自定义了MongoDB镜像（build: ./mongoDump/database），确认该目录下是否存在docker-entrypoint-initdb.d文件夹？官方Mongo镜像只会在第一次启动（数据目录为空）时执行该目录下的脚本，但如果你的自定义镜像修改了这个逻辑，可能导致每次重启都重新初始化数据。

内容的提问来源于stack exchange，提问作者Thanos Sakis