0

We are using a mongo replica set of 4 members, and one arbiter. There are 3 physical sites, all mongo servers can talk to each other:

Site 1 (west coast) site1-mg01 site1-mg02

Site 2 (east coast) site2-mg03 site2-mg04

Site 3 (cloud, arbiter only) site3-mgarbiter

We have a Java client. I'd prefer the client never to connect to the Mongo servers in the other site, even if one of their servers becomes primary (lag will kill the app.) Or put a different way

Site 1 Java App connects to site1-mg01 and site1-mg02

Site 2 JavaApp connects to site2-mg03 and site2-mg04

Is it acceptable for a client to only know about part of a replica set? So if the web client can physically ONLY reach site 1, and I set up my replica set as follows:

"site1-mg01:270xx,site1-mg02:270xx"

Will my client be negatively impacted? The way I assume it works, is long as one of those servers is primary, it will connect fine? And if a Site 2 Mongo becomes the primary, I just can't connect?

Community
  • 1
  • 1
javatestcase
  • 682
  • 1
  • 10
  • 25

2 Answers2

1

In Mongo, all writes are made to the primary. If your clients are 'read only', you can use 'nearest' read preference in your queries. Another option is to connect to the non primary node and set rs.slaveOk to allow the client to read. https://docs.mongodb.org/v3.0/reference/method/rs.slaveOk/

hope it helps.

Yair Harel
  • 441
  • 3
  • 10
1

Mongo replica set - does a client need to know about all of them?

No - TBD

Is it acceptable for a client to only know about part of a replica set?

As a matter of fact, for the client application - through the Java driver - it is enough to "know" only about a single member of the set. The rest of the set members are accessible via that single member configuration.

Will my client be negatively impacted?

Yes, in that case of setting only a single data center members portion of the set, you don't protect yourself from cases where that data center is down and your client can't initially connect to the set. You should better configure a server address array containing first a member of the west coast, then a member of the east coast. An order which should be inverted by the east coast client application.

To be on the safe side, you should configure three members server addresses to guarantee that if the set is functioning, you can connect to at least one of the three of the surviving nodes. In that case, add the arbiter as it is in a neutral data center It is most likely that if two members go away, they are both from the same DC.

The way I assume it works, is long as one of those servers is primary, it will connect fine?

As said, you don't necessarily need to connect to the primary, only to a member that knows where the primary is.

And if a Site 2 Mongo becomes the primary, I just can't connect?

Yes you can.

I'd prefer the client never to connect to the Mongo servers in the other site even if one of their servers becomes primary

The client will of course always write to the Primary, doesn't matter on which DC. If you want the application to always read from it's designated data center, the best way to achieve it is via read preference tag sets.

Ori Dar
  • 18,687
  • 5
  • 58
  • 72
  • Thanks for the feedback. Preference tags sound promising, but can they say DON'T talk to Site 2? I tried out my setup, and as you suggested, it discovers site2-mg03 and site2-mg04, then then throws a com.mongodb.MongoSocketOpenException when it can't talk to them. Reading your link, it doesn't sound like tags would STOP connections? – javatestcase Feb 16 '16 at 18:53
  • @javatestcase it's hard to say what went wrong without code and rs configuration being shown. If you configure the west coast member with a proper tag and set a `ReadPreference` properly, it should work. I don't know what you mean by *discover*. The remote site is always reachable by the application, but using a suitable `TagSet` for a read operation, it should read data from the "local" site members. – Ori Dar Feb 17 '16 at 09:52