determine storageEngine specificity in docs
(DOCS-4856)
|
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | mongodb-3.0 |
| Fix Version/s: | 01112017-cleanup |
| Type: | Sub-task | Priority: | Major - P3 |
| Reporter: | Mark Callaghan | Assignee: | Kay Kim (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | storage | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 8 years, 32 weeks, 2 days ago |
| Description |
|
In http://docs.mongodb.org/manual/core/replica-set-sync/ a few sections can be updated for new storage engines. — Is this true for all storage engines from the "Multithreaded Replication" section. If it is true then it limits my ability to have long running queries on a replica that isn't getting far behind on replication. 'While applying a batch, MongoDB blocks all reads. As a result, secondaries can never return data that reflects a state that never existed on the primary.' — The "Prefetching Indexes" section is only true for mmapv1, which is explained in the docs for the referenced parameter, secondaryIndexPrefetch, but I think the docs here could be updated. |
| Comments |
| Comment by Githook User [ 06/Jul/15 ] |
|
Author: {u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message: |
| Comment by Eric Milkie [ 31/Mar/15 ] |
|
"Pre-Fetching Indexes to Improve Replication Throughput" should be MMAPv1 only. The Multithreaded Replication section, in the 3.0 and master docs branches, can be changed to something like this: While applying a batch, MongoDB blocks all read operations. As a result, secondary read queries can never return data that reflect a state that never existed on the primary. |