Can MongoDB be configured to sit behind a load balancer?

Question

According to this post:

In a single replica set, you cannot distribute writes, they all must go to the primary. You can distribute reads to the secondaries already, via Read Preferences as you deem appropriate. The driver keeps track of what is a primary and what is a secondary and routes queries appropriately.

According to the Mongo docs:

You may also deploy a group of mongos instances and use a proxy/load balancer between the application and the mongos. In these deployments, you must configure the load balancer for client affinity so that every connection from a single client reaches the same mongos.

So basically, it seems like if you've got a single replica set of 3 nodes, you can't really use a proxy/load balancer since all writes need to go to the primary and you need client affinity... so all reads also need to go to the primary.

What I'm thinking though is that it might be possible to have applications connect to a load balancer. The load balancer would route all requests to the primary (not very balanced, but whatever)... until/unless the primary went down - at which point the load balancer would start routing requests to a "new primary".

I'm not sure if this is possible however since, how would the load balancer know which mongo server had been elected the new primary (and thus where it should route new requests)?

Assuming it was possible, this would achieve a degree of redundancy, in case the primary ever goes down... I'm also hoping it would also have the side effect of avoiding stale writes when a network partition occurs, since the load balancer (and thus all DB clients) would only ever connect to a single primary.

Or is this a stupid question...

Answer 1

You need to read closely. A mongos is the query router providing access to a sharded cluster. A mongos is well aware of the underlying replica sets, the (re-)elections and last but not least, which node is primary of a shard's replica set.

Having multiple mongos has various advantages. A usual setup would be to have one mongos per application server. That setup may be undesired, for example because you have automatic scaling for your application servers based on load. You can set up a multitude of machines with mongos query routers and pass all of these instances via your connection string to your application servers. The problem here is that all queries would go to the first mongos listed. In order to circumvent that, you could put a tcp load balancer in front of your mongos instances.

For replica sets, nothing of this is necessary. First of all, (most, that is all major) drivers are well aware of the fact they are connecting to a replica set, if properly configured. With replica set aware drivers, they automatically determine the current primary for writes. For sort of load balancing, there is a notion called read preference. Simplified: On a per query basis, you can choose to read from a secondary, accepting the possibility to read outdated data, as per eventual consistency. Again, (most) drivers are aware of that and there is no need for a load balancer.

Answer 2

recently I attended the online course provided by mongo university M202 and in the CHAPTER 3 FAULT TOLERANCE AND AVAILABILITY it specifically talks about these 2 questions:

• Load balancer with a replica set;
• Load balancer in a sharding environment.

Within a replica set having a load balancer is discouraged because the load balancer should be aware about the actual primary server and also it should know about read preferences in the cluster.
So the answer given about the firs question is that no, it is not possible to have an external load balancer over a replica set cluster.
For the second question the answer given is that is possible to have a load balancer in front of a sharded system but with only one caveat, which is that the load balancer should stay sticky to the mongos addressed, something very similar to the session affinity in web application.
The reason is that during a request, i.e. a read from a cursor, the retrieval of the next elements will fail if the load balancer would use a different mongos from the one chosen before.