[DOCS-2299] Document that slavedelayed shard members are likely not to be useful in a sharded cluster Created: 25/Nov/13 Updated: 16/Mar/15 Resolved: 25/Feb/14 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | v1.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Richard Kreuter (Inactive) | Assignee: | Sam Kleinman (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 9 years, 51 weeks, 1 day ago |
| Description |
|
If the purpose of a slavedelayed secondary is to facilitate "going back" to a previous database state, then slavedelayed secondaries are of little value in a sharded cluster in general (i.e., without placing constraints on the operation of the cluster, e.g., that the balancer hasn't run lately). The docs ought to note this fact. Whether the docs describe various edge cases where they might be useful is outside the scope of this request, though I assign little value to documenting marginal edge cases or convoluted operational practices. |
| Comments |
| Comment by Githook User [ 25/Feb/14 ] |
|
Author: {u'username': u'tychoish', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}Message: |
| Comment by Githook User [ 25/Feb/14 ] |
|
Author: {u'username': u'tychoish', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}Message: |