[17:28:17] <guardian> but all the docs to resync a replica don't help in a case of a 1-node replica set
[17:30:06] <d4rkp1r4t3> Joaolvcm[m]: queryable snapshots are available on a read only mongod instance next to your ops manager application. in the case of cloud mongodb backup - atlas does not support querying those, only legacy backup snapshots
[17:33:37] <d4rkp1r4t3> guardian: correct. that's because running a single node replica set doesn't make a whole lot of sense, replica sets are deployed for providing redudnancy. in your case with a 1-node replica set, you just start the mongod instance and let it recover automatically from its last checkpoint and it will replay the journal files that are already available on disk. no need to resync as there is
[17:33:37] <d4rkp1r4t3> nothing to resync from. no need to --repair as there is nothing to repair since the journal is there to help with the recovery.
[17:35:14] <guardian> d4rkp1r4t3: it makes sense when you want transactions
[17:35:49] <guardian> and no the journal didn't help recovering from that power outage, while --repair did
[17:36:16] <guardian> then I gave the __system role to my admin user so that I can remove "repaired": "true" from the replica info
[17:36:23] <guardian> and everything was good again
[17:36:31] <guardian> and then I compared that to a restored backup
[17:36:47] <guardian> so yeah I answered my own question
[17:52:24] <d4rkp1r4t3> I do see now in the docs that in the rare case of disk level corruption --repair is used as a last resort - though in most deployments its not needed since there are other members to sync from as you already discovered.
[17:54:07] <d4rkp1r4t3> Still, it doesn't make a whole lot of sense that your applications atomicty requirements take priority over being highly available. Who cares if your queries are atomic if there is nothing to query from? Maybe for testing that is okay but if you need to --repair then it sounds like the data isn't being used for testing.