Any there any specific issues for deploying MongoDB on btrfs? I am using SSD for storage.
I’ve read in docs that XFS is the recommended one. But I’m also planning on having a snapshot backup feature in future, or might even have to extend across multiple disks.
Will there be any performance issues in case of btrfs?
Follow the docs and use XFS. In many databases it is by default more performant. In my experience(own benchmarks ~mongo 3.4) the benefits of btrfs and zfs are not worth the performance trade off.
For snapshots you can use XFS on top of LVM.
Specifically for backups I have previously deployed a hidden, non-voting member on ZFS as part of a replica set.
My workload will mainly consist of write and read operations. There will be rarely any update operations. Will btrfs still have adverse effect of performance?
Hi,
I would still recommend XFS since that’s what’s been extensively tested and proved to be the best solution. Other filesystems may still work fine, but there could be some hidden caveats or performance implications, so that the drawback may outweighs the benefits, as @chris had pointed out.
As one example, there is an old ticket that identified performance issues with Ext4 with WiredTiger: SERVER-18314. There might be similar (undiscovered) issues with btrfs.
Having said that, if you think that btrfs serves your use case a lot better than XFS and you’re willing to take the chance, you might want to test the configuration extensively before deploying it in production to minimize any surprises.
Best regards,
Kevin
Welcome to the community @Dushyant_Bangal!
Btrfs is not widely used or tested with MongoDB. An important consideration is that by default Btrfs is a Copy On Write (COW) filesystem which will not be ideal for use cases with frequently updated data files (for example, databases and VMs). Fragmentation can lead to significant storage wear which will reduce the lifespan of your storage device.
As mentioned on the Btrfs Gotchas wiki page:
Files with a lot of random writes can become heavily fragmented (10000+ extents) causing thrashing on HDDs and excessive multi-second spikes of CPU load on systems with an SSD or large amount a RAM
The consequences of write activity over time are difficult to predict, but you could try simulating your predicted workload. It sounds like you may be planning for an insert-only workload, which should be less problematic for Btrfs than a workload including updates and deletes.
If you do plan on using Btrfs, I would definitely look into tuning Btrfs mount options for the volume hosting your MongoDB storage.dbPath (for example, possibly using the nodatacow option for a workload involving updates & deletes). Btrfs also has some features like checksums and compression which duplicate work performed in MongoDB’s WiredTiger storage engine by default, so if performance is a consideration you probably don’t want to have overlapping features enabled.
It would be excellent if you can share any Btrfs experience with the community so there is more information on what does (or doesn’t) work well with MongoDB. Btrfs tuning experience for other databases should also be relevant.
For a production environment I would strongly recommend using XFS for the broadest experience and support. You can use LVM (Logical Volume Manager) with XFS for more operational flexibility, including creating logical volumes spanning multiple physical disks and taking consistent snapshots.
Regards,
Stennie