[DOCS-9780] Deploy Shard Cluster Clarity Created: 16/Jan/17 Updated: 30/Oct/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | 3.4.0 |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Ronald Petty | Assignee: | Ravind Kumar (Inactive) |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 1 year, 14 weeks, 2 days ago |
| Epic Link: | DOCSP-1769 |
| Story Points: | 2 |
| Description |
|
Hello, I am unable to follow these instructions to set up a shard without replication. https://github.com/mongodb/docs/blob/master/source/tutorial/deploy-shard-cluster.txt It clearly states in the instructions that you should be able to, but if I search through the bug tracker I see evidence you can't run without a config server replica set. I think the page could benefit from separating single instance vs replicated instances. It raises the learning curve unnecessarily (especially for learning.) I am happy to do a PR, but have not figured it out myself. I am using 3.4 community via APT. |
| Comments |
| Comment by Education Bot [ 31/Oct/22 ] | |||||||||||||||||||||||||
|
Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you! | |||||||||||||||||||||||||
| Comment by Ronald Petty [ 18/Jan/17 ] | |||||||||||||||||||||||||
|
Thank you for all the help. I was able to get the cluster going with your clarification. If it matters, I still believe having the 'abbreviated' version first help as to not conflate best practices with kicking the tires. Again, that could just be me. After getting it running, I recommend adding a brief CRUD example (for loop, etc.) against mongos just to show it is actually working. I think a full round trip example would be the best bang for someone buck. Again thanks for taking the time to clarify and provide advice, I appreciate it. Ron | |||||||||||||||||||||||||
| Comment by Ravind Kumar (Inactive) [ 17/Jan/17 ] | |||||||||||||||||||||||||
|
I think I see what you're looking for. I'd be happy to look over this tutorial again and see what improvements can be made. I cannot provide an exact timeframe for this, but its on my radar. In the meantime, I can provide quick-and-simple setup instructions for you here. Please use the mongo shell for this. For a bare-minimum test system, you can get away with:
That's just about it - the instructions on that page still apply in general. When I set up a sharding testing environment, I usually go with single-member replica sets for all shards and the config server. The following is a sample of how I might launch a simple test system.
I hope this is of some help. For any additional guidance, I strongly recommend our google group as it is a better forum for support and guidance questions. I should note, sharding is a technically complicated and dense subject matter. I am glad you are looking to work through it. From personal experience, if you run into errors launching a mongod or mongos, check the produced logs. I also strongly recommend our on demand university courses. The current course is still open for registration, I believe, and there are many for each language. I linked M101P, but you can see there are many others. The M101 courses cover sharded clusters, deployments, and other important information. I've taken the courses myself and found them invaluable. I hope you consider looking into them for adding to your own skillset as well. | |||||||||||||||||||||||||
| Comment by Ronald Petty [ 17/Jan/17 ] | |||||||||||||||||||||||||
|
Hi Ravind, You are confirming what I am reading. The issue I see is there are several ideas being conflated here, single node, replicate set (including single node replica sets,) best practices, test set, etc. Its a lot of instructions but unclear goal. I suppose for myself, a rewrite where it kinda flows like this would help procedural people like myself!
I see much of the above in the article, but when trying to build the smallest test system, I have not been successful at this point. Let me refocus on what is to be replicated and what is not. For me, I am not looking for production HA, I am looking for sharding, to instruct how sharding works (not HA.) Thanks for your time. Ron | |||||||||||||||||||||||||
| Comment by Ravind Kumar (Inactive) [ 17/Jan/17 ] | |||||||||||||||||||||||||
|
Hello, Thank you for filing a DOCS ticket. I'm a little confused as to the issue: are you referring to the instructions duplicated below?
Those instructions are specific to the config server component of the sharded cluster, and are correct as written. You cannot deploy a standalone mongod as a config server. Each mongod in the config server replica set must have both the configsvr and replSet options. You also mentioned setting up a shard as a standalone. A shard can be either a standalone mongod instance, or a replica set. What is important is running the mongod with the shardsvr option. The instructions on shards are duplicated below:
You are correct that we don't specify standalone in this tutorial. This is on purpose, as a standalone mongod does not lend itself towards high availability, which is an important aspect of a sharded cluster. A single-member replica set deployment is relatively straightforward, even compared to a standalone, and has the advantage of easily expanding to a 3 member replica set later. Someone using a standalone in a sharded cluster cannot move to a replicated environment for that shard without taking downtime, which is not ideal. This tutorials goal is a sharded cluster that can work for both testing and production environments without taking downtime for expanding shards or the config server replica sets for high availability. It may help to distinguish between a standalone deployment and a single member replica set. A single member replica set is a mongod running with the --replSet option, but with no other connected members in the replica set. In this state, the single mongod acts as the Primary. This deployment pattern works for both shards and the config server replica set. A single member replica set is not the same thing as a standalone mongod. A standalone is not a part of any replica set and cannot be configured to join one without being restarted. Hopefully this sheds some light on your concern - if not, it might help if you can provide some additional details as to what you are trying to do, e.g. deploying with only standalones, or majority standalones. |