[SERVER-22530] improve capped collection replicated inserts Created: 09/Feb/16 Updated: 19/Dec/16 Resolved: 11/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Matt Dannenberg |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Operating System: | ALL | ||||
| Backport Requested: |
v3.2
|
||||
| Steps To Reproduce: | Run the insert_capped.js workload on a replica set to see the issue. |
||||
| Sprint: | Repl 10 (02/19/16) | ||||
| Participants: | |||||
| Description |
|
Vectored insert does not support inserting into a capped collection, so if you do more than a light load of inserts into a capped collection, secondaries will flood their logs with:
This also severely impacts performance since every batch insert throws and catches an exception. We should avoid trying to do vector inserts on capped collections. We can use the CachingCappedChecker for this, or some other clever technique. |
| Comments |
| Comment by Githook User [ 11/Feb/16 ] |
|
Author: {u'username': u'dannenberg', u'name': u'matt dannenberg', u'email': u'matt.dannenberg@10gen.com'}Message: |
| Comment by Matt Dannenberg [ 10/Feb/16 ] |
|
Where does the insert_capped.js workload live? |