[SERVER-7515] idempotence violation when intermediate document exceeds size threshold Created: 30/Oct/12 Updated: 22/May/23 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Aaron Staple | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | bkp, former-robust-initial-sync, idempotency, initialSync | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
The update code enforces different size constraints when modifiers are applied, including:
One of these constraints may be violated when an update is applied to a future version of a document present on a secondary, even though the constraint was not violated when the operation was performed on the primary. If this occurs, data from another field may not be properly replicated to the secondary. And if during initial sync of a replica set the initial sync may fail. Tests:
|
| Comments |
| Comment by Siyuan Zhou [ 17/Oct/19 ] | ||||||||
|
Now that we don't fetch missing documents anymore, fixing this will need to change a fundamental size limit of BSON object in the codebase. Since this bug is very rare in the past several years, we are closing it. Feel free to reopen it if this happens again. | ||||||||
| Comment by Siyuan Zhou [ 27/Jul/18 ] | ||||||||
|
Just to add another concrete example. I and U represent insert and update respectively.
| ||||||||
| Comment by David Henderson [ 31/Jan/18 ] | ||||||||
|
I've been hit by this one again, this time doing an initial sync from WT to WT (3.4.10) | ||||||||
| Comment by David Henderson [ 26/Apr/17 ] | ||||||||
|
Yes, I think so - skip the doc after the error, and pull a complete copy at the end. | ||||||||
| Comment by Eric Milkie [ 26/Apr/17 ] | ||||||||
|
I see now. The work for this ticket should be to change the code to treat "document became too large" update errors the same as we current treat "document is missing" update errors. | ||||||||
| Comment by David Henderson [ 26/Apr/17 ] | ||||||||
|
Basically as outlined in the marked-as-dupe
| ||||||||
| Comment by Eric Milkie [ 26/Apr/17 ] | ||||||||
|
Hi David, | ||||||||
| Comment by David Henderson [ 26/Apr/17 ] | ||||||||
|
Any progress on this one? Happened a couple of times now during intial syncs from MMAP -> WT | ||||||||
| Comment by Eric Milkie [ 08/Sep/16 ] | ||||||||
|
To recover from this situation, we need to copy the full document from the sync source. I believe initial sync may already do this, since it treats all update errors with the same behavior; we should confirm this. |