I’m fairly new to MongoDB. I’m running 1 Primary and 2 Secondaries. I’ve noticed that which ever is elected to be primary, the WiredTigerLAS.wt keeps on growing, and in the end, causing MongoDB to shutdown due to its size. I’ve read so far that WiredTigerLAS.wt contains dirty files/cache. I’ve also read that via “mongod”, the WiredTigerLAS.wt file shrinks and fixes the problem. I’ve also read that declaring a max cache overflow value will just terminate MongoDB with a fatal assertion error when the max declared value is reached.
What is the best alternative fix instead of using “mongod” time and time again to fix this issue? Will increasing the RAM solve the issue?
The WiredTigerLAS.wt file was removed in MongoDB 4.4, so I would encourage you to upgrade to the latest MongoDB version (5.0.4, currently).
To provide some context, the WiredTigerLAS.wt file was used as a cache overflow mechanism. That is, if WT needs to use more cache than what is configured, it will use the LAS file like a swap file.
Typically, there are many reasons why the WiredTigerLAS.wt file can keep growing. Some of the common ones are:
A no-timeout cursor, forcing WT to hold on to longer and longer history, and thus using more and more cache
Delayed secondaries, or secondaries that cannot keep up with the primary
The use of arbiters
During a particularly bad case, the LAS file can keep growing with no limit. However, note that the LAS file is like a swap for cache, so restarting the mongod instance would remove the file automatically.
Newer MongoDB versions do not use the LAS file mechanism anymore, and is using an alternative method to keep track of historical data. Thus I would try to upgrade to the latest MongoDB version and see if the issue persist.
Hi Kevinadi! Thank you for the warm welcome and for the reply. I forgot to mention my current version is 4.0.3. I’ve noticed that restarting Mongo, shrinks WiredTigerLAS.wt. Is it as equally safe to just remove the said file thru deletion (rm -rf) via a linux terminal? Also, if a Write request is sent to the Primary node, it is backed-up or written instantly in the 2 Secondaries(I am using a replica set, with no arbiters, just 2 secondaries)? If it is not written instantly to the 2 secondaries, does the WiredTigerLAS.wt contain the pending data to be written/backuped-up to the 2 secondaries?
Is it as equally safe to just remove the said file thru deletion (rm -rf) via a linux terminal?
No it’s not safe to modify anything inside the dbpath when mongod is running (I would also say it’s not safe to modify the dbpath even when mongod is not running). You’d need to shut it down and restart it, and the LAS file should be gone. If it appears in a smaller size, that means it’s a new file.
Also, if a Write request is sent to the Primary node, it is backed-up or written instantly in the 2 Secondaries
If a write request is sent to the primary, it will be replicated to the secondaries as quickly as possible. The write will be acknowledged depending on your write concern setting.
does the WiredTigerLAS.wt contain the pending data to be written/backuped-up to the 2 secondaries
No the LAS file doesn’t contain data to be written. It’s a cache overflow mechanism.
If you would like to learn more about MongoDB basics, I would recommend you to take a look at some of the free courses in MongoDB university. There are courses for pretty much everything there, from the very basic to advanced topics. I’m certain it’ll be worth your time.
