[DOCS-774] Documentation doesn't cover how to set up "hidden" nodes using a sharded cluster. Created: 19/Nov/12 Updated: 19/Nov/12 Resolved: 19/Nov/12 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | William Zola | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Days since reply: | 11 years, 13 weeks, 2 days ago | ||||||||||||
| Description |
|
Hidden members don't work well with a sharded cluster. The normal use case is for a single replica set. In that case, you can directly connect to the single hidden node and send your read-only testing queries there. However, you cannot query a sharded collection and have it target the hidden nodes. Because those nodes are marked as 'hidden', there is no way to have the 'mongos' direct queries to those nodes. The way to implement "hidden" nodes in a sharded cluster is to use the new tag-aware sharding features. In your three-node replica set, you'd tag one node as 'testing', and set it to priority 0, so it could never become master. You'd then tag the other two nodes as 'working'. You would then have to set a read preference in your application: the production applications would set a read preference of 'working', and the testing/analytics application would set a read preference of 'testing'. |
| Comments |
| Comment by Sam Kleinman (Inactive) [ 19/Nov/12 ] |
|
dupe. Will link and close. |
| Comment by Scott Hernandez (Inactive) [ 19/Nov/12 ] |
|
We should not come at this from the hidden perspective but about creating different groups of replicas for different work-loads. I think this also a dup, but I haven't searched for it yet. |