[SERVER-19753] Do not allow force sync from stale source Created: 04/Aug/15 Updated: 14/Mar/17 Resolved: 14/Mar/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Scott Hernandez (Inactive) | Assignee: | Judah Schvimer |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Sprint: | Repl 2017-04-17 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||
| Description |
|
When the syncFrom command is used, the server should connect to the source provided and check that it is at least up to the current fetched position before calling into the topology coordinator to set it. |
| Comments |
| Comment by Judah Schvimer [ 14/Mar/17 ] |
|
Yes, we now check that the sync source's last applied OpTime is greater than our last fetched OpTime on the first oplog entry batch. |
| Comment by Spencer Brody (Inactive) [ 10/Mar/17 ] |
|
I believe this may have been fixed by |
| Comment by Spencer Brody (Inactive) [ 11/Nov/16 ] |
|
We need to investigate how much of a problem this is. For instance, does this allow you to induce a rollback of committed ops by setting your sync source to someone out of date? |