MongoDB无法旋转日志，无法打开已删除的文件

我有一个与[1]中报告的问题类似的问题，当发生日志循环时，MongoDB日志文件保持打开状态，即

deleted

。然而，我相信根本原因是完全不同的，所以我提出了一个新问题。长短不一的是，当这种情况发生时（并非一直如此），我最终没有任何Mongo日志；有时，删除的日志文件会保留很长时间，因为它的大小变得太大而成为一个问题

与[1]不同，我在Mongo[2]中直接设置了日志旋转。具体做法如下：

systemLog:
  verbosity: 0
  destination: file
  path: "/SOME_PATH/mongo.log"
  logAppend: true
  timeStampFormat: iso8601-utc
  logRotate: reopen

rw,nodev,relatime,seclabel,attr2,inode64,noquota

在设置方面：我正在RHEL7.4上运行MongoDB4.2.9（WireTiger）。数据库位于XFS文件系统上。我们为XFS提供的安装选项如下：

systemLog:
  verbosity: 0
  destination: file
  path: "/SOME_PATH/mongo.log"
  logAppend: true
  timeStampFormat: iso8601-utc
  logRotate: reopen

rw,nodev,relatime,seclabel,attr2,inode64,noquota

任何关于导致这种行为的原因的指示都将不胜感激。提前感谢您抽出时间

更新1

谢谢大家的指点。我现在更好地理解了配置，但我仍然认为存在一些问题。总而言之，除了告诉MongoDB在log rotate上重新打开文件的设置之外，我还使用了

logrotate

命令。配置与[3]中的建议非常相似：

# rotate log every day
daily

# or if size limit exceeded
size 100M

# number of rotations to keep
rotate 5

# don't error if log is missing
missingok

# don't rotate if empty
notifempty

# compress rotated log file
compress

# permissions of rotated logs
create 644 SOMEUSER SOMEGROUP

# run post-rotate once per rotation, not once per file (see 'man logrotate')
sharedscripts

# 1. Signal to MongoDB to start a new log file.
# 2. Delete the empty 0-byte files left from compression.
postrotate
    /bin/kill -SIGUSR1 $(cat /SOMEDIR/PIDFILE.pid 2> /dev/null) > /dev/null 2>&1
    find /SOMEDIR/ -size 0c -delete
  endscript

主要区别实际上是稍微复杂一点的

postrotate

命令，尽管它在语义上似乎与[3]中的操作相同，例如：

kill -USR1 $(/usr/sbin/pidof mongod)

无论如何，目前的日志轮换配置似乎发生的情况是，MongoDB似乎很少获得

SIGUSR1

，但不创建新的日志文件。我强调“似乎/似乎”，因为我没有任何确凿的证据证明这一点，因为在受控环境下进行复制是一个非常棘手的问题。但我们可以比较这两种情况。我发现，在大多数情况下，原木滚压是有效的：

-rw-r--r--. 1 SOMEUSER SOMEGROUP 34M  May 5  10:51 mongo.log
-rw-------. 1 SOMEUSER SOMEGROUP 9.2M Feb 25 2020  mongo.log-20200225.gz
-rw-------. 1 SOMEUSER SOMEGROUP 8.3M Nov 17 03:39 mongo.log-20201117.gz
-rw-r--r--. 1 SOMEUSER SOMEGROUP 8.6M Jan 30 03:19 mongo.log-20210130.gz
-rw-------. 1 SOMEUSER SOMEGROUP 8.6M Feb 27 03:31 mongo.log-20210227.gz
...

但是，有时MongoDB似乎没有创建新的日志文件，而是保留已删除的文件句柄（注意缺少的

mongo.log

）：

我并不完全清楚，在收到

SIGUSR1

信号后，如何获得更多关于MongoDB正在做什么的信息。我还注意到，在遇到问题之前，我成功地进行了多次旋转，这可能只是巧合，但我想知道是否是最终旋转导致了问题（例如，

rotate 5

）。我会继续调查，但欢迎提供更多的建议。提前谢谢

[1]

[2]

---

[3]

如何轮换日志？轮换是根据日期、所有其他内容、删除等分发日志。需要在操作系统级别上进行。请注意，在适当的日志轮换中，首先移动/删除日志文件，然后执行

logrotate

命令。默认情况下，在向日志文件报告活动数据时，MongoDB仅在响应logRotate命令或mongod或mongos进程接收到来自操作系统的SIGUSR1信号时旋转日志。如果使用

logRotate:reopen

，则日志记录通常与

logRotate

或类似工具一起完成，如中所述。当然，您可以使用MongoDB内部日志旋转（即

logRotate:rename

），但是您仍然需要调用操作系统来删除旧的日志文件。