Re: Replication architecture with 2 data centers

[A. Jesse Jiryu Davis]

See this document for geographic distribution of replica-set members and configuring read preferences in the Java driver:

http://www.mongodb.org/display/DOCS/Read+Preferences+and+Tagging+in+The+Java+Driver

1. Use secondaryPreferred reads for data that you don't need up-to-the-second consistency for. The Java driver will, by default, read from the member with the shortest ping time, plus member within 15ms of that shortest ping-time, so you most likely won't need to futz with tagging to read from RS members in the correct data-center.

2. Put an equal number of members of each replica set in each data center (e.g., three members in each)

3. Put an arbiter for each RS outside of any data center, e.g. on a cloud server. Thus if you lose one data center or the other, the members in the surviving DC plus the arbiter form a majority of the original RS. Now we're describing 7-member RSes: 3 data members in each DC, plus an arbiter somewhere else.

4. If you have three members of each RS in each DC, then even if you lose a DC, you'll continue to have a primary and two secondaries.

On Monday, October 29, 2012 9:17:21 AM UTC-4, ronitF wrote:

I'm designing a Mongo replica set for our production environment.
We have two data centers (geographically distributed).
We have 6 replica sets, 3 in each data center.
Using Java driver.
The requirements are:
1. Read can be done against all secondary members (in both data centers).
2. Replication capabilities within each data center for minor failures.
3. Automatic failover when an entire data center is down.
4. Primary should always be elected. Minimum of 2 secondary members for read.

What is the best replication architecture we can use ?

Thanks !

[Russell Smith]

The language you've used makes me ask;

You say 6 replica sets….do you mean 6 replica set members, or 6 replica sets?

If it's 6 replica set members, half in each DC, you're heading for a trouble. You always have to use an odd number of replica set members if you want elections to work properly (unless you've been fiddling with the votes per member?); http://docs.mongodb.org/manual/administration/replica-sets/


Russ
Rainforest | +1-650-919-3216 | rainforestqa.com

> --
> You received this message because you are subscribed to the Google
> Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com
> See also the IRC channel -- freenode.net#mongodb

[Russell Smith]

Then you should just make sure the number of members in a single
replicaset is odd, otherwise failure may result in the whole set going
read-only.

Do this by adding* another voting member, an arbiter or a full node will
do, as well as read the link I put below.


Russ

* or removing - but then you won't have two min at all times?

On 30 Oct 2012, at 0:48, ronitF wrote:

> I mean 6 replica set members.
> Thank u.
> בתאריך יום שני, 29 באוקטובר 2012 18:52:51 UTC+2,
> מאת Russell Smith:

>
>> The language you've used makes me ask;
>>
>> You say 6 replica sets….do you mean 6 replica set members, or 6
>> replica
>> sets?
>>
>> If it's 6 replica set members, half in each DC, you're heading for a
>> trouble. You always have to use an odd number of replica set members
>> if
>> you want elections to work properly (unless you've been fiddling with
>> the
>> votes per member?);
>> http://docs.mongodb.org/manual/administration/replica-sets/
>>
>>
>> Russ
>> Rainforest | +1-650-919-3216 | rainforestqa.com
>>
>> On Oct 29, 2012, at 7:36 AM, A. Jesse Jiryu Davis

>> <je...@10gen.com<javascript:>>

>>> mongod...@googlegroups.com<javascript:>

>>> To unsubscribe from this group, send email to

>>> mongodb-user...@googlegroups.com <javascript:>