|
Cause for this ticket.
I had a secondary which would crash on duplicate key indexes when it rejoined a replica set. It didn't make any sense. I would like more control over the replica set itself in terms of how it works.
Two threads:
a. A download thread to be executed.
b. A thread executing the commands downloaded.
In any case, it would be nice to have two threads doing the following:
1. You can stop and start any of the threads.
2. You can skip a command if a thread stops executing.
3. When the execute thread dies tor stops, an option to just have it stop being part of a replica set — but not to let it crash.
4. Continue to execute the commands downloaded even if disconnected from the replica set upto the last known good point in the replica set.
|