0

I have deployed 3 MongoDB nodes(node-1, node-2, node-3) in AWS. The first two nodes (node-1, node-2) are deployed in Virginia region and the third node(node-3) is deployed in Oregon region and enabled VPC peering and the replication is working fine.

Current Scenario ::

Virginia : Node-1 (Primary) and Node-2 (Secondary)

Oregon: Node-3 (Secondary)

Failover Scenario::

if the Virginia region goes down,

1. Both the Node-1 and Node-2 will also be down.
2. Third node (Node-3) has to be Primary

And the Virginia region comes back,

1. Node-1 and Node-2 has to be secondary
2. Node-3 has to continue being primary

But, Now if the Virginia goes down the third node(node-3) is still in Secondary. I have to manually make the node as Primary. Is there any automated way or alternate solution to do this.

  • 1
    With three node replica set, if you lose two nodes, there is no majority. That's why that last node is at Secondary state.. To prevent "split-brain" situation. – JJussi May 29 '18 at 13:52
0

I have deployed 3 MongoDB nodes(node-1, node-2, node-3) in AWS. The first two nodes (node-1, node-2) are deployed in Virginia region and the third node(node-3) is deployed in Oregon region and enabled VPC peering and the replication is working fine . But, Now if the Virginia goes down the third node(node-3) is still in Secondary. I have to manually make the node as Primary. Is there any automated way or alternate solution to do this.

Yes, As per MongoDB Blog documentation here MongoDB Atlas ensures high availability with a fault-tolerant and self-healing architecture. Replica set members are distributed across availability zones in a customer’s selected region; should a node fail, the election and failover process happen automatically without intervention. You can also choose from 41 regions across AWS, Azure, GCP, ensuring that your managed databases are in close proximity to your application servers for minimal geographic latency.

You can deploy across multiple regions for better availability guarantees, meaning that replica set members in additional regions will participate in the election and automated failover process should your primary fail. Note that you can also select your preferred region; this is the region where reads and writes will default to assuming that there are no active failure or failover conditions.

You can also deploy read-only replica set members. Read-only replica set members allow you to optimize for local reads (reduce read latency) across different geographic regions using a single MongoDB deployment. As the name suggests, these replica set members will not participate in the election and failover process and can never be elected to a primary replica set member.

For further your ref here and here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.