[SERVER-1594] mongos should work with replica-set (without sharding) Created: 09/Aug/10 Updated: 16/Jan/24 |
|
| Status: | Blocked |
| Project: | Core Server |
| Component/s: | Replication, Sharding |
| Affects Version/s: | 1.6.0 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Scott Hernandez (Inactive) | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 146 |
| Labels: | oldshardingemea | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||||||
| Participants: |
Abhishek Kona, Alexander Komyagin, Alex Simenduev, Backlog - Catalog and Routing, Chuck Desmarais, David Henderson, Dominic Baines, Donald Scott, Glenn Maynard, jagadeep suggala, Marco Lovato, Markus Gattol, Philippe David, Scott Hernandez, Sebastian Riedel, S Porcina, Stephan Bösebeck, Thibault Meyer, Thijs Cadier, Thomas Parrott, ttnn
|
||||||||||||
| Description |
|
Change the mongos router to work with a non-sharding replica set. |
| Comments |
| Comment by Alexander Komyagin [ 27/Sep/19 ] |
|
I built a prototype for this functionality (not supported): https://github.com/alex-thc/monguac/tree/new |
| Comment by jagadeep suggala [ 18/Mar/19 ] |
|
+1 |
| Comment by ttnn [ 27/Mar/18 ] |
|
+1 |
| Comment by Donald Scott [ 13/Jan/17 ] |
|
Fundamentally there needs to be an option to load balance across a replica-set WITHOUT sharding. Many people have workloads which are too small to warrant sharding, yet require replica sets for redundancy. There people then have maintenance and reporting scripts which would permit stale data, but we have no mechanism to intelligently route the query to the most available server. |
| Comment by Dominic Baines [ 02/Jun/16 ] |
|
Nothing in ages is this still being looked at? This would be an extremely useful feature. |
| Comment by Chuck Desmarais [ 30/Jun/15 ] |
|
+1 we got around it creating a single shard cluster, but hadn't really wanted to do that, This feature would have saved us an annoying trip into driver edge cases. |
| Comment by Thijs Cadier [ 22/Oct/14 ] |
|
+1, this would be extremely useful to us. |
| Comment by David Henderson [ 07/Oct/14 ] |
|
I've cross-posted this response to a blog post here: http://emptysqua.re/blog/server-discovery-and-monitoring-spec/ I think this view (from the previous comment, that there is little value to more widespread use of mongos) is a little short-sighted - as far as I can see, there are other benefits of having this logic in the mongos (as well as removing the complexity from the driver developers): For ease, I'm going to refer throughout to a mongo instance (i.e. a single mongod / a replicaset / a sharded cluster) as a "target".
If, on the other hand, you had the option to connect to anything via a mongos, as a standard layer, you would only have to: For some background, we're running with:
In conclusion, here's my wishlist for an ideal mongos solution:
Any thoughts would be appreciated. |
| Comment by Sebastian Riedel [ 07/Sep/14 ] |
|
There is so much unnecessary work going into replica set support (especially read preferences) for all the different drivers, it boggles the mind. Such an important part of the infrastructure should really be owned by the core server. |
| Comment by Abhishek Kona [ 27/Feb/14 ] |
|
This kind of critical infrastructure should ideally be owned by Mongo. Is this in the roadmap for 2.6? |
| Comment by Glenn Maynard [ 24/Jan/14 ] |
|
Big +1. I wasted a lot of time today bringing up a server because of replica set driver weirdness. (Pymongo requires the replica set name in the URL for some reason and my Mongo host doesn't include it. Pymongo also has a whole separate top-level class just for replica sets.) Users and drivers shouldn't have to care whether they're connecting to a standalone server, a replica set or a cluster, and mongos could mask all this and eliminate whole categories of driver bugs and usage errors. Another example is how easy it is to end up using a non-replica-set mongo URL when connecting to a replica set, and this will "seem to work" for a long time if it happens to be the primary, then suddenly fail later after a failover. This can be hidden within mongos and handled automatically. |
| Comment by Thomas Parrott [ 15/Jan/14 ] |
|
This would be a really useful feature, as we can let the mongos deal with maintaining persistent connections to the replica sets, meaning PHP/Apache clients dont have a delay whilst they connect to all the nodes. |
| Comment by Abhishek Kona [ 30/Dec/13 ] |
|
I would like to use mongos as a connection proxy to save on the number of connections it can make to mongo. |
| Comment by Stephan Bösebeck [ 28/May/13 ] |
|
Need this feature, too... very much so. |
| Comment by Philippe David [ 12/Mar/13 ] |
|
A lot of efforts have been done to code the replica set connection/reconnection logic in several drivers. The client-side replica set code is indeed complex, but even for a language like PHP which is quite popular I am not yet satisfied by the driver. To me it sounds very reasonnable to have this complexity only once in a generic proxy and not in every driver. If it means running a mongos daemon on localhost for every PHP client, fine. As long as it's more stable. +1 |
| Comment by Thibault Meyer [ 26/Jan/13 ] |
|
So i'm looking for this kind of feature today. You have my vote too. |
| Comment by Marco Lovato [ 21/Nov/12 ] |
|
We are just about to install MongoDB for our production site (replacing Oracle) and we did a lot of testing using Mongos, but our production site will definetivelly use replica-set. Then we found this. Best |
| Comment by S Porcina [ 29/Mar/12 ] |
|
The feature gets my vote too. |
| Comment by Alex Simenduev [ 22/Jan/12 ] |
|
Is this still planned? When to expect for this future, I'm desperately waiting for this future... |
| Comment by Markus Gattol [ 21/Nov/10 ] |
|
Resolving this one would also enable the case where nginx-gridfs could read from secondaries as opposed to primaries only: |