[SERVER-6984] Initial sync can fail, or break future replication, when updates shrink or grow docs in capped collections Created: 10/Sep/12 Updated: 06/Dec/22 Resolved: 15/Jan/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | 2.2.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kevin Matulef | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Done | Votes: | 11 |
| Labels: | repl1, sync | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Storage Execution
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Description |
|
Right now we allow updates on docs in capped collections, as long as docs don't grow past the size of their initial allocation. However, during initial sync, the data is cloned but the initial allocation size is lost on the secondary. So if inserts or updates which affect document size occur during the cloning process, when replaying the docs you can get an error message saying "objects in a capped ns cannot grow." For instance, this happens if the following sequence of ops happens during initial sync:
If the smaller version of the doc is cloned during the initial sync, you will get an error message at the end of the initial sync when it goes to apply the ops:
Even if initial sync manages to succeed, it's possible that future updates which grow a document on the primary will break replication, because there is no space for the doc to grow on the secondary. I've verified that this can occur, and the error message is similar to above. |
| Comments |
| Comment by Eric Milkie [ 15/Jan/16 ] |
|
Due to |
| Comment by Asya Kamsky [ 03/Jun/15 ] |
|
rosmo - capped collections are most effective when they are used as append-only inserts and tailing reads - they are not as effective for updates, so certainly eliminating update operations would avoid this issue. If updates cannot be avoided then making sure that updates don't change the size of the document would be the next best thing. Asya |
| Comment by Taneli Leppä [ 01/Jun/15 ] |
|
This affects 2.4.12 as well. Any decent workaround? |
| Comment by David Burley [ 19/Feb/13 ] |
|
Any update on this issue? Are there any workarounds for it in the mean time? |
| Comment by Aaron Staple [ 10/Sep/12 ] |
|
Here's a (potentially old) test (from a duplicate ticket): Author: {u'login': u'astaple', u'name': u'Aaron', u'email': u'aaron@10gen.com'}Message: |
| Comment by Aaron Staple [ 10/Sep/12 ] |
|
matulef Sure I'll make the other a dup since you have more info here. |
| Comment by Aaron Staple [ 10/Sep/12 ] |
|
Also see |
| Comment by Kevin Matulef [ 10/Sep/12 ] |
|
Options for fixing this are:
|