Details
-
Bug
-
Resolution: Done
-
Major - P3
-
None
-
None
-
Fully Compatible
-
ALL
-
Repl 2017-10-02, Repl 2017-10-23
Description
At startup, the RSSync thread is responsible for transitioning the node from STARTUP2 to RECOVERING. At the same time the BGSync thread may decide that rollback is necessary and try to transition to ROLLBACK. If BGSync wins the race and we go into ROLLBACK first, RSSync can then transition us to RECOVERING while rollback is still running. If this happens before the rollback process sets minValid, it can cause RSSync to go live as SECONDARY. In the right kind of network partition this could theoretically lead to us running and being elected PRIMARY.
While I don't see any synchronization that would actively prevent this case, it seems fairly unlikely to happen in practice because it would require BGSync to complete several network round trips before RSSync is able to do the small amount of work it does before setting RECOVERING.
Attachments
Issue Links
- is duplicated by
-
SERVER-27982 Unnecessary loop in RSDataSync
-
- Closed
-