### MongoDB Docker Compose 不断重启的原因及解决方案 #### 1. **日志排查** 当 MongoDB 容器持续重启时，首要任务是从容器的日志中查找具体错误信息。可以使用以下命令查看最近的日志输出： ```bash docker logs mongo ``` 如果发现类似 `FATAL: bind_ip includes 0.0.0.0, but we are unable to listen on it` 的错误消息，则表明网络配置存在问题[^3]。 --- #### 2. **常见原因及其解决办法** ##### (1) **存储卷权限不足** 即使在 compose 文件中指定了挂载路径 `- ./data/db:/data/db` ，但如果宿主机上的对应目录缺乏适当权限，MongoDB 将无法写入数据文件从而触发自动退出机制。 - **验证方法**: 登录到宿主机并检查目标位置的访问属性: ```bash ls -ld ./data/db/ ``` - **修正方式**: 确保该文件夹拥有足够的读写执行权利给运行中的进程用户（通常是 root）。可以通过调整 ACL 实现这一点或者干脆赋予完全控制权作为临时手段: ```bash sudo chown -R $(id -u):$(id -g) ./data/db/ ``` ##### (2) **内存资源耗尽** 某些情况下，由于物理 RAM 太少加上交换空间有限，操作系统会杀死占用大量内存的大程序实例——这就是所谓的 OOM Killer 行动。 - **诊断步骤**: 查看系统 dmesg 输出寻找任何关于 oom_killer 动作的信息片段； ```bash dmesg | grep -i kill ``` - **优化策略**: - 提高可用内存总量要么减少其他消耗大户的工作负载量级; - 设置合理的 ulimit 参数限制单个进程所能使用的最大堆栈大小等指标; ##### (3) **端口冲突** Compose 文件里声明监听外部接口 `"ports": ["27017:27017"]`, 若本地已有另一个服务占用了相同编号的 TCP 连接点也会造成循环崩溃现象发生. - **探测手段**: 执行 netstat/nmap 工具扫描开放状况 ; ```bash ss -tuln |grep :27017 ``` - **规避措施**: 更改暴露出来的公共地址部分为别的闲置数值区间即可避开干扰源. ##### (4) **初始化脚本失败** 环境变量如 `MONGO_INITDB_ROOT_USERNAME` 和密码字段如果没有被正确定义好也可能引起反复尝试建立超级管理员账户却始终不成功的恶性循环局面出现. - **调试技巧**: 移除所有预设好的认证选项重新单纯依靠匿名模式启动起来观察表现变化情形后再逐步添加回安全防护层面上去逐一排除干扰因素的影响范围直到恢复正常运作状态为止. --- #### 3. **综合改进后的 docker-compose.yml 示例** 基于以上分析结果给出一个更加健壮稳定的版本供参考采用: ```yaml version: '3.1' services: mongodb: image: mongo:latest container_name: mongo environment: - TZ=Asia/Shanghai - MONGO_INITDB_ROOT_USERNAME=root - MONGO_INITDB_ROOT_PASSWORD=mongo123 healthcheck: test: ["CMD", "mongosh", "--eval", "db.runCommand('ping')"] interval: 10s timeout: 5s retries: 5 volumes: - type: bind source: ./data/db target: /data/db consistency: delegated ports: - "27018:27017" restart: unless-stopped networks: - mongo-net networks: mongo-net: driver: bridge ``` 注意这里做了几处改动：一是更改公开映射端口号避免潜在碰撞风险；二是引入健康监测模块帮助快速定位异常节点所在；三是明确指定 volume 类型增强跨平台兼容性特性支持等等[^4]. ---