Is it possible to revert the KV store storage engine migration in a standalone environment with SE 8.x.
Example: If I am migrating the KV store storage engine from MMAP to WiredTiger.
Can I revert this change i.e. migrate from WireTiger to MMAP.
If it is possible what are the steps to do so. Is there any doc for this?
I can see doc/command for migrating from MMAP to WiredTiger
splunk migrate kvstore-storage-engine --target-engine wiredTiger
Need similar steps for the reverse condition.
Please help.
Assuming it was upgraded using storageEngineMigration=true in its server.conf file, here are the backout steps I've used to roll back to the mmapv1 MongoDB on a standalone Splunk instance. It uses the backup of the old mmapv1 MongoDB taken at upgrade time.
NOTE: this could potentially cause data loss, if new data has gone into the migrated WiredTiger storage engine. It really only makes sense if done soon after upgrade.
1. Stop Splunk Enterprise. Do not use the -f option.
2. Open server.conf in the $SPLUNK_HOME/etc/system/local/ directory
3. Edit the kvstore stanza and remove the following entries:
storageEngine = wiredTiger
storageEngineMigration=true
4. Save the server.conf file.
5. Change to the $SPLUNK_DB/kvstore directory
6. Rename the new mongo directory
mv mongo mongo_wiredtiger
7. Restore the previous mmpapv1 MongoDB under old_db directory
a) List the date stamped directory name
ls -ld old_db/*
b) Move and rename the old_db date stamped directory to mongo
mv old_db/<date stamped directory> mongo && ls -ld $SPLUNK_DB/kvstore/mongo
8. Restart splunk
splunk start
9. In the CLI, run the splunk show kvstore-status command
splunk show kvstore-status
10. This listed storage engine should be as follows
storageEngine : mmapv1
NOTE: this back out will not work after a SHC migration to use the Wired Tiger storage engine, as it does not take a snapshot (old_db) of the mmapv1 database at upgrade time. It's not clear in the docs, but by the looks of it there is no easy way to revert a SHC back to the using mmapv1 after an upgrade. If it all works then there is no good reason to revert to mmapv1. Sadly, change control requirements usually require a documented backout plan.
Another possibility (I've not tried this) for a SHC restore to mmapv1 MongoDB could be:
NOTE: understandably, the method listed above has no guaranteed consistency and would only ever be required in a disaster recovery scenario.
FINALLY: As noted, I've not tried this on an SHC in my own environment (I was to late and had upgraded already) so validate it in your own test environments, if using.
@bmunson_splunk Can you help on this?