Check my understanding of Active/Active DC Architecture
70 views
Skip to first unread message
barker...@gmail.com
Feb 12, 2016, 7:41:28 AM2/12/16
to mongodb-user
Hi All
I am new to MongoDB and was hoping to validate my understanding of something. Any help would be much appreciated - apologies if it's a silly question!
I have watched the webinar and taken a look at the slides for the MongoDB Webinar: Deploying MongoDB to Production in Data Centers and the Cloud. See https://www.mongodb.com/presentations/webinar-deploying-mongodb-production-data-centers-and-cloud
On slide 34, it says that with 3 data centre replia set deployments you get:
- Durable commits (w: "majority")
- Automatic failover and recovery
- Lose any server
- Lose any data centre
On slide 37, there is an active/active data centre deployment:
- 2 replica set members per shard in DC West
- 1 Arbiter per shard in DC Central
- 2 replica set members per shard in DC East
I understand a majority write concern in this configuration to be 3 members.
The slide says this architecture tolerates server, rack, data centre failures, and network partitions.
Thinking through the scenario where a data centre is lost, I have reached the following conclusion:
If DC West or DC East is lost, then we loose 2 data-bearing nodes, and are left with 2 data-bearing nodes e.g. we can no longer get a majority write concern of 3, because we have only 2 data-bearing nodes
In this situation, we would need to do one of the following:
1) Reconfigure the application to use a write concern of 2 (not majority). That allows writes to succeed and ensures commits are durable
2) Set votes for the servers in the lost data centre to 0. In MongoDB 3.0, a majority of voting members is required for a majority write concern. We now have 2 data-bearing voting members, hence a majority of 2 can be reached
So, despite this being a 3 data centre deployment we cannot have both durable commits and automatic failover. Only one or the other.
If I need 2 members in West and East, and require both durable commits and automatic failover, I should make the arbiter in Central a data-bearing node.
If anyone could either confirm my understanding or explain what I've missed it would be greatly appreciated.
I am new to MongoDB and was hoping to validate my understanding of something. Any help would be much appreciated - apologies if it's a silly question!
I have watched the webinar and taken a look at the slides for the MongoDB Webinar: Deploying MongoDB to Production in Data Centers and the Cloud. See https://www.mongodb.com/presentations/webinar-deploying-mongodb-production-data-centers-and-cloud
On slide 34, it says that with 3 data centre replia set deployments you get:
- Durable commits (w: "majority")
- Automatic failover and recovery
- Lose any server
- Lose any data centre
On slide 37, there is an active/active data centre deployment:
- 2 replica set members per shard in DC West
- 1 Arbiter per shard in DC Central
- 2 replica set members per shard in DC East
I understand a majority write concern in this configuration to be 3 members.
The slide says this architecture tolerates server, rack, data centre failures, and network partitions.
Thinking through the scenario where a data centre is lost, I have reached the following conclusion:
If DC West or DC East is lost, then we loose 2 data-bearing nodes, and are left with 2 data-bearing nodes e.g. we can no longer get a majority write concern of 3, because we have only 2 data-bearing nodes
In this situation, we would need to do one of the following:
1) Reconfigure the application to use a write concern of 2 (not majority). That allows writes to succeed and ensures commits are durable
2) Set votes for the servers in the lost data centre to 0. In MongoDB 3.0, a majority of voting members is required for a majority write concern. We now have 2 data-bearing voting members, hence a majority of 2 can be reached
So, despite this being a 3 data centre deployment we cannot have both durable commits and automatic failover. Only one or the other.
If I need 2 members in West and East, and require both durable commits and automatic failover, I should make the arbiter in Central a data-bearing node.
If anyone could either confirm my understanding or explain what I've missed it would be greatly appreciated.
Kevin Adistambha
Feb 18, 2016, 10:16:35 PM2/18/16
to mongodb-user
Hello,
Yes your understanding is correct. However, there are a couple of things that may need clarifications.
1. The scenario in slide 34 provides you with durable commits and automatic failover.
2. The scenario in slide 37 provides you with automatic failover and can tolerate server, rack, data centre failures, and network partitions, but does not provide you with durable commits. Please note that this is not a 3 data center deployment. This is essentially a 2 data center deployment with automatic failover. This point is mentioned in slide 35, where the arbiter is marked as
[Anywhere] instead of DC.
Slides 47-58 details the necessary steps to recover from a failure situation with 2 data center deployment. The steps you provided to recover from this failure scenario is quite similar, and shows a good summary for correcting this situation.
Best regards,
Kevin
barker...@gmail.com
Feb 21, 2016, 8:12:17 AM2/21/16
to mongodb-user
Thank you, Kevin - good to know I'm on the right track...
Reply all
Reply to author
Forward
0 new messages