[SERVER-26848] Exit catchup mode when not syncing more data Created: 31/Oct/16 Updated: 10/May/18 Resolved: 21/Apr/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.4.6, 3.5.7 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Siyuan Zhou |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||||||||||||||
| Backport Requested: |
v3.4
|
||||||||||||||||||||||||||||
| Sprint: | Repl 2017-01-23, Repl 2017-02-13, Repl 2017-03-06, Repl 2017-03-27, Repl 2017-04-17, Repl 2017-05-08 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||
| Description |
|
Currently we expose one parameter to the replica set config - catchUpTimeoutMillis (defaults to 2 seconds) - which controls how long to stay in catchup mode after winning an election. We should exit catchup mode when the primary finds itself the most up-to-date after refreshing heaertbeats. |
| Comments |
| Comment by Githook User [ 16/Jun/17 ] |
|
Author: {u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}Message: (cherry picked from commit e4f20f24ddbb9cea2255df6fe0cfd34ddeb0263e) |
| Comment by Githook User [ 16/Jun/17 ] |
|
Author: {u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}Message: (cherry picked from commit 4680351e3fe6f8f47c04440f1c5d1232a4ab7b2d) |
| Comment by Githook User [ 21/Apr/17 ] |
|
Author: {u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}Message: This reverts commit fac33fe5a6814169c9c6131d80f1b325c74647da. |
| Comment by Githook User [ 21/Apr/17 ] |
|
Author: {u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}Message: This reverts commit c08590a6ac9dc54c9d910822d47ea17140b56f89. |
| Comment by Githook User [ 20/Apr/17 ] |
|
Author: {u'username': u'guoyr', u'name': u'Robert Guo', u'email': u'robert.guo@10gen.com'}Message: Revert " This reverts commit d0c851e2f4bfea514e22c97af1838640d2849a8c. |
| Comment by Githook User [ 20/Apr/17 ] |
|
Author: {u'username': u'guoyr', u'name': u'Robert Guo', u'email': u'robert.guo@10gen.com'}Message: Revert " This reverts commit 7109d453e5a264ba77093b9b068d1eaa056ec837. |
| Comment by Githook User [ 19/Apr/17 ] |
|
Author: {u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}Message: |
| Comment by Githook User [ 19/Apr/17 ] |
|
Author: {u'username': u'visualzhou', u'name': u'Siyuan Zhou', u'email': u'siyuan.zhou@mongodb.com'}Message: |
| Comment by Spencer Brody (Inactive) [ 13/Dec/16 ] |
|
If we make the time spent applying operations during catchup infinite, we need a plan for what to do if we lose connectivity to the sync source for any reason. I propose that in that case, we spend the node selection timeout amount of time again re-searching for a node to sync from and continue where we left off. |