Hi @Chinmaya_Das ,
I’d strongly discourage option #2 per the warnings in `mongod --repair’ documentation:
- Only use
mongod --repair
if you have no other options. The operation removes and does not save any corrupt data during the repair process.- Avoid running
--repair
against a replica set member:
- To repair a replica set member, if you have an intact copy of your data available (e.g. a recent backup or an intact member of the replica set), restore from that intact copy instead(see Resync a Member of a Replica Set).
- If you do choose to run
mongod --repair
against a replica set member and the operation modifies the data or the metadata, you must still perform a full resync in order for the member to rejoin the replica set.
If mongod
fails to start as a service but runs via manual invocation with the same config file, my guess would be that there is a problem with file or directory permissions that you are avoiding by running mongod
as the root
user. I would check permissions for any paths mentioned in your /etc/mongod.conf
(step 6).
If permissions aren’t the issue, I’d try this suggestion.
If you’re still stuck, please share more details including:
- specific version of MongoDB server
- type of deployment (standalone, replica set, or sharded cluster)
- O/S version
Regards,
Stennie