I hope this is the correct section to ask my question: I’m developing a performance testing framework for MongoDB deployments, and I would like to efficiently reset a MongoDB replica set after every test run. My current solution is to simply terminate all the nodes, removes all the data and logs from the file system and redeploy the whole thing from scratch: this takes around 15 seconds, mostly due to the election process. Is it possible to simply instruct the deployment to “nuke” itself, without redeploying?
I found this code snippet on StackOveflow:
//drops user collections, clears system collections
db.getCollectionNames().forEach( function(collection_name) {
if (collection_name.indexOf("system.") == -1)
db[collection_name].drop();
else
db[collection_name].remove({});
});
I was wondering if it is enough to guarantee a completely clean replica set
For a completely clean replica set (no oplog or local database history) with persistent storage, the approach you are taking is already the most efficient as long as re-deploying only refers to recreating the replica set config (i.e. you don’t need to reinstall the binaries).
An alternative which isn’t completely clean would be to call db.dropDatabase() on all non-system databases (excluding local, config, and admin). This would not clear system data like the replication oplog, sessions, and user/role configuration so doesn’t seem appropriate for performance testing.
The code snippet you provided drops all collections in the current database. Dropping a collection includes the data and any associated indexes, but you cannot drop the local.oplog.rs collection or the local database while running in replica set mode. This leaves some significant history (eg past oplog entries) that could affect performance testing as compared to a clean install.
There is no supported method to “nuke” the data on a running replica set: shutting down all members, removing the dbpath contents, and then recreating the replica set is the most efficient approach.
Thanks, I’ll give it a look, although it will probably have the same issue as my custom scripts (Wait around 15 seconds for the election process to “settle in”, then start testing)
mlaunch automates standing up a local test deployment (all members running on the same machine) so I expect that wouldn’t be suitable for performance testing.