[SERVER-41577] change max_time_ms_repl_targeting.js to do its initial insert via w:2 Created: 07/Jun/19 Updated: 29/Oct/23 Resolved: 28/Jun/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.0-rc2, 4.3.1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mira Carey | Assignee: | Rahul Sundararaman (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Backport Requested: |
v4.2
|
||||||||
| Sprint: | Service Arch 2019-07-01 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 10 | ||||||||
| Description |
|
max_time_ms_repl_targeting.js performs an insert, then attempts to read that value back with a maxtimems set against a secondary without satisfiable tags. Part of the sanity check for that test includes running a query against the lone secondary (which absolutely should be able to pick up the record), but this races with replicating the write. BF-11945 illustrates the number of times we lose that race. Changing the initial write to a w:2 write would ensure it's on the secondary when we got to look for it there. |
| Comments |
| Comment by Githook User [ 01/Jul/19 ] |
|
Author: {'name': 'Rahul Sundararaman', 'username': 'rsbballguy', 'email': 'rahul.sundararaman@10gen.com'}Message: (cherry picked from commit 7f2630cf028f38d45dd5d9e3415d44f31b3cc030) |
| Comment by Githook User [ 28/Jun/19 ] |
|
Author: {'name': 'Rahul Sundararaman', 'username': 'rsbballguy', 'email': 'rahul.sundararaman@10gen.com'}Message: |