logrotate不生效主因是mongod未读取配置文件，常见于systemd服务硬编码--logpath参数覆盖配置；需确保systemlog.path（绝对路径且有写权限）、logrotate: rename、logappend: true三者同时配置正确。
为什么 logRotate 不生效？检查 mongod 启动方式是否覆盖了配置
直接执行 db.adminCommand({logRotate: 1}) 返回成功，但磁盘空间没释放——大概率是 mongod 没读取你改的配置文件。Linux 下常见两种启动方式：systemd 服务和手动 mongod --config /etc/mongod.conf。如果用 systemd，它可能默认加载 /lib/systemd/system/mongod.service，而该文件里常硬编码了 --logpath 参数，会直接覆盖 mongod.conf 中的 systemLog.path 和 systemLog.logRotate 设置。
验证方法：运行 ps aux | grep mongod，看实际启动命令是否含 --logpath；若存在，优先修改对应 service 文件里的 ExecStart 行，或改用配置文件驱动（删掉命令行参数，确保只留 --config）。
启用 logRotate 必须同时配齐的三个配置项
仅设 systemLog.logRotate: rename 不够，MongoDB 要求三个参数协同工作：
-
systemLog.path：必须是绝对路径，且 mongod 进程有写权限（常见坑：路径指向/var/log/mongodb/，但目录属主是 root） -
systemLog.logRotate: rename：唯一支持的值，copy或none会被忽略 -
systemLog.logAppend: true：必须为true，否则每次重启都会覆盖旧日志，logRotate失去意义
示例片段（/etc/mongod.conf）：
systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log logRotate: rename
手动触发 logRotate 后，旧文件名带时间戳但不自动压缩或删除
MongoDB 的 logRotate 只做重命名（如 mongod.log → mongod.log.2024-05-20T08-30-15），不压缩、不清理、不限数量。这意味着磁盘仍会持续增长，需额外手段管控：
- 用
logrotate（系统级工具）接管 MongoDB 日志：在/etc/logrotate.d/mongodb中配置压缩、保留份数、按大小/时间轮转 - 避免用
find /var/log/mongodb -name "mongod.log.*" -mtime +7 -delete这类脚本——若恰逢logRotate执行中，可能删掉正在写入的临时文件 - 副本集所有节点需单独配置，
logRotate不跨节点同步，也不能通过主节点命令触发从节点日志轮转
副本集环境下特别注意日志路径与权限隔离
多个 mongod 实例共用同一日志目录（比如都写 /var/log/mongodb/）时，logRotate 可能因文件锁或权限冲突失败。尤其当使用 systemctl start mongod@node1 启动多实例时：
- 每个实例的
systemLog.path必须指向独立子路径，例如/var/log/mongodb/node1/mongod.log - 确保对应目录存在且属主为
mongod用户（chown -R mongod:mongod /var/log/mongodb/node1） - 不要依赖
logRotate清理journal/目录或data/db/下的 oplog，那些是数据文件，删错直接导致副本集不可用
真正要清理的只是文本日志，而它们往往被忽略——直到某天 df -h 报警才发现占了上百 GB。
