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 ?
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 ?
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/
> 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 !
> -- > You received this message because you are subscribed to the Google
> Groups "mongodb-user" group.
> To post to this group, send email to mongodb-user@googlegroups.com
> To unsubscribe from this group, send email to
> mongodb-user+unsubscribe@googlegroups.com
> See also the IRC channel -- freenode.net#mongodb
> 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 ?
> 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/
> > 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 !
> > -- > > 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<javascript:> > > To unsubscribe from this group, send email to > > mongodb-user...@googlegroups.com <javascript:> > > See also the IRC channel -- freenode.net#mongodb
> 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/
>>> 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 !
>>> --
>>> 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<javascript:>
>>> To unsubscribe from this group, send email to
>>> mongodb-user...@googlegroups.com <javascript:>
>>> See also the IRC channel -- freenode.net#mongodb
> -- > You received this message because you are subscribed to the Google
> Groups "mongodb-user" group.
> To post to this group, send email to mongodb-user@googlegroups.com
> To unsubscribe from this group, send email to
> mongodb-user+unsubscribe@googlegroups.com
> See also the IRC channel -- freenode.net#mongodb
