-
Type: Bug
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
ALL
-
Repl 2019-10-21, Repl 2019-11-04, Repl 2019-11-18
One of my scripts for testing Flow Control prompts an election. I've noticed that in some runs of the test, there is a spike in reported lastCommitted lag that occurs immediately after the election. This spike occurred both when the election chose the same primary as previously and when the election chose a different node as primary. Flow Control is a consumer of lastCommitted lag, so it will respond to the spike and throttle writes. I don't see why lastCommitted lag should have a reason to spike, particularly if the same primary is elected, so I believe this behavior should be investigated.
- is related to
-
SERVER-32703 Secondary can take a couple minutes to re-establish sync source after network partition
- Closed
- related to
-
SERVER-44634 Account for election down time when calculating majority committed lag
- Closed