[SERVER-11172] Unable to vote for primary when replica sets running on Virtual Machine Created: 14/Oct/13  Updated: 20/Nov/13  Resolved: 04/Nov/13

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.4.3
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: chuck reeves Assignee: Unassigned
Resolution: Done Votes: 0
Labels: replication
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Centos 6.3, Mongo 2.4.3 Running on VMWare vCloud


Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Create a replica set across a vCloud
Bring down primary
Secondaries are unable to vote for a new primary since there is no latency between network/io/cpu etc

Participants:

 Description   

I have three servers running on three VM's on the same hardware. Because of this there is no network/io/cpu lag. When the primary goes down, the secondaries are unable to vote for a new primary since they are all equal. The workaround for this would be to set weight for the 3 servers, or have an arbiter.



 Comments   
Comment by Amalia Hawkins [ 04/Nov/13 ]

Awesome, glad to know you're no longer having this issue! Let us know if it comes back, and good luck moving forward.

Comment by chuck reeves [ 04/Nov/13 ]

No I was not able to reproduce this issue. I am guessing that there was just something going on with the setup I had

Comment by Amalia Hawkins [ 04/Nov/13 ]

Hi, Chuck! Were you able to reproduce the issue?

Comment by chuck reeves [ 14/Oct/13 ]

I'll have to make the changes to our staging server in order to reproduce. I will be able to send in a couple of days

Comment by Eliot Horowitz (Inactive) [ 14/Oct/13 ]

Latency between nodes isn't something you need.
Can you send the replica set config and the log from the 2 remaining nodes?

Generated at Thu Feb 08 03:25:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.