I want to keep my /data folder on a remote host, separated from the host where I install and run my mongoDB instances.
On the event of updating these mongoDB instances to a next major version, I want to just simply keep the /data folder unchanged (suppose I have backed up the folder). After reconnection, would WiredTiger still persist the data (as binary files) with 100% reliability?
Welcome to the community @Thang_Vu.
Mounting your dbPath from a remote host is an atypical deployment approach as you may see network-related performance issues.
However, as long as performance isn’t a concern, mongod has exclusive read/write access to the files in the dbPath, and the mount point supports fsync() system calls this approach should work. The MongoDB server will refuse to start if incorrect permissions or an unsupported filesystem are detected.
The Remote Filesystems section in the MongoDB Production Notes has some suggested options if you happen to be using NFS.
What is your motivation for using a remote filesystem? Is your remote filesystem on the same physical host as the host for your MongoDB instances?
This is the same scenario as a normal MongoDB major version upgrade. You need to follow the relevant upgrade instructions (including prerequisites) in the release notes for the version you are upgrading to.
Regards,
Stennie
Hi Stennie, thank you for you quick reply. Your response has everything I need, especially about the remote filesystem section in the MongoDB production notes which I missed.
Evaluation the possibility of using a remote filesystem is one of the concern from our customer. We developers are kept away from the true motivation, so for this question I cannot give you a solid answer. The filesystem would be very likely be placed on a different physical host with the VMs for the mongod instances.
Hi,
If your team is kept away from the deployment side of things (but still providing recommendations or potentially supporting production issues), I would strongly recommend not using a remote filesystem. If your customers push back on this suggestion, perhaps they will share their motivation. They may be trying to apply deployment patterns which are more typical with other products, but not recommendable for MongoDB deployments.
Regards,
Stennie
Hi Stennie, thank you for your advices. It appears that, there were some miscommunications between the teams. The initial idea is to use a mounted directory within the same mongoDB instance’s host, not a remote directory entirely. In other words, mounting is now separated from mongoDB: instead of actually mounting the dbPath, we create a mounting point in advance and use it as our dbPath. Would you recommend such an approach?
Hi,
Mounting a directory for the dbPath is fine, and a very different proposition from mounting a remote filesystem. You still need to ensure file & directory permissions are correct. I also suggest restarting your system at least once after adding new mount points to make sure these correctly persist on a reboot (although testing regimes are up to you).
In some cases it can even make sense to Separate Components onto Different Storage Devices so data, journal, and log paths are not contending for I/O. There is also some flexibility in storage layout with options like directoryPerDB and directoryForIndexes.
However, I’d try to avoid adding unnecessary complexity to your deployment without understanding the potential implications for administration and your chosen backup approach.
Regards,
Stennie
Hi Stennie,
That’s everything I wanted to know, thank you very much for the insights. I’m glad to be a part of this community!
Regards,
Thang Vu