-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
None
-
Affects Version/s: 3.2.9, 3.3.11
-
Component/s: Replication
-
None
-
Environment:Containerized MongoDB on Linux Debian Jessie coming from Official Docker Hub repo
-
Replication
-
ALL
-
(copied to CRM)
We have a replicaset of MongoDB running in 3.2.9 (the last stable release).
We experiment the fact that the file WiredTigerLAS.wt is growing without limits :
$ ll WiredTigerLAS.wt -rw-r--r-- 1 mongodb users 134003650560 Sep 28 11:59 WiredTigerLAS.wt
It seems very similar to the case describe here : SERVER-21585 but this issue should have been fixed into 3.2.9.
I try with 3.3.x, and the same problems occurs.
Removing the file and restarting solve (temporary) the issue.
In our RS, we have some members in 3.0.x (in which we get the PRIMARY) and some other in 3.2.x. The issue only occurs in the members in 3.2.x which are forced to be hidden to avoid crashing a PRIMARY.
Our config :
root$ more /etc/mongodb.conf
# mongod.conf
# for documentation of all options, see:
# http://docs.mongodb.org/manual/reference/configuration-options/
# Where and how to store data.
storage:
dbPath: /datas/mongodb
journal:
enabled: true
directoryPerDB: true
engine: wiredTiger
wiredTiger:
engineConfig:
# Set cacheSizeGB to the size of RAM authorized in container (60% of the available RAM on instance)
cacheSizeGB: 1
processManagement:
fork: false
# where to write logging data.
systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log
# network interfaces
net:
port: 27017
http:
enabled: false
JSONPEnabled: false
RESTInterfaceEnabled: false
ssl:
mode: disabled
replication:
oplogSizeMB: 990
replSetName: kluck
enableMajorityReadConcern: true
Removing the enableMajorityReadConcern: true seems to resolve the issue.