[SERVER-5669] possible for _slaves data (from which wtimeout is checked) to become stale w.r.t. heartbeat Created: 20/Apr/12 Updated: 10/Dec/14 Resolved: 07/Mar/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Greg Studer | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Participants: |
| Description |
|
If there's a delay processing a getMore for the oplog it's possible the heartbeat time will be later than the _slaves time (shown in local.slaves). _slaves potentially could be updated from the heartbeat optime if > the optime found from getMore(), or wtimeout could also take the heartbeat optime into account if > _slaves optime. Test demonstrates if you insert a 10s delay, for example, before the processing of getMores() |
| Comments |
| Comment by Eric Milkie [ 07/Mar/14 ] |
|
This will be fixed in 2.6 via the SyncSourceFeedback mechanism, which no longer uses getMores to update _slaves, so there is less chance it will be blocked for some reason. |