Trying Out Replica Set Priorities

Posted bykchodorowPosted inMongoDBTags:,
Respect my prioritah!

As promised in an earlier post, replica set priorities for MongoDB are now committed and will be available in 1.9.0, which should be coming out soon.

Priorities allow you to give weights to the servers, saying, “I want server X to be primary whenever possible.” Priorities can range from 0.0-100.0.

To use priorities, download the latest binaries (“Development Release (Unstable) – Nightly”) from the MongoDB site. You have to have all members of the set running 1.9.0- or higher, as older versions object strongly to priorities other than 0 and 1.

Once you have the latest code installed, start up your three servers (A, B, and C) and create the replica set:

> // on server A
> rs.initiate()
> rs.add("B")
> rs.add("C")

Suppose we want B to be the preferred primary. And C‘s a backup server, but it could be primary if we really need it. So, we can adjust the priorities:

> config = rs.conf()
>
> // the default priority is 1
>
> B = config.members[1]
> B.priority = 2
>
> C = config.members[2]
> C.priority = .5
>
> // always increment the version number when reconfiguring
> config.version++
> rs.reconfig(config)

In a few seconds, A will step down and B will take over as primary.

Protip: the actual values of the priorities don’t matter, it’s just the relative values: B > A > C. B could have a priority of 100 and C could have a priority of .00001 and the set would behave exactly the same.

FAQ

(Based on coworkers+the 12 hours it’s been committed)

What if A steps down and B is behind? Won’t I lose data?

No. A will only step down if B is within 10 seconds of synced. Once A steps down, B will sync until it’s up-to-date and (only then) become master.

Okay, but I want B to be primary now. Can I force that?

Yes, now-ish. Run this on A:

> db.adminCommand({replSetStepDown : 300, force : true})

This forces A to step down immediately (for 300 seconds). B will sync to it until it is up-to-date, then become primary.

I forgot to upgrade one of my servers before setting crazy priorities and now it’s complaining. What do I do?

Shut it down and restart it with 1.9.0. Setting non-1/0 priorities won’t harm anything with earlier versions, it just won’t work.

So, when should I use votes?

Almost never! Please ignore votes (in all versions, not just 1.9.0), unless: 1) you’re trying to have a replica set with more than 7 members or 2) you want to wedge your replica set into a primary-less state.

14 thoughts on “Trying Out Replica Set Priorities”

    1. Yup! Should be in a couple of days. We spent a long time testing 1.8 and not committing and new code, so I think there was a lot of pent-up developer energy for making new features… wait’ll you see all the stuff in the 1.9 series!

      Like

      Reply

  3. Out of curiosity, why between 0 and 100? Since all that matters is that the possible priorities are well-ordered it seems like it could have just as easily been “use any number”, or if you are keeping it limited isn’t 0-1.0 perhaps a bit more natural?

    I’m nit-picking. Glad to see this out there – good stuff!

    Like

    Reply

    1. It was the original range Dwight mentioned, so I think it was just arbitrary. I think 0-100 gives people more natural options than 0-1: it’s “nicer” to have priorities 1, 2, and 3, instead of .1, .2, and .3.

      Like

      Reply

    1. It shouldn’t change at all, I think that FAQ entry is mixing up votes and priority. Priority is unrelated to how many votes an arbiter has in an election. It doesn’t make much sense to talk about an arbiters priority (although you could set it to whatever) as it will never become primary.

      Also, we generally recommend an odd number of servers in a replica set to avoid ties, as “majority” is computed from the total number of members, not the up members.

      Like

      Reply

      2. If we have an even number of secondaries with different priorities, do we still need an arbiter to break the tie?

        Like

      3. If we have an even number of secondaries with different priorities, do we still need an arbiter to break the tie?

        Like

      4. The real reason to have an arbiter is to maximize the chances of ending up with a majority. For example, if you have data center 1 (DC1) and data center 2 (DC2) and they get disconnected, you want one of them to still be able to reach a majority of servers. If DC1 has 3 servers and DC2 has 3 server, you’ll have 6 secondaries and your system will be read-only. If DC1 also has an arbiter, DC1 will have 4 servers (out of 7 total) and so be able to elect a primary. So arbiters are still useful as voters.

        As a tie breaker: I don’t think ties are even possible without a transient network error in the latest code.

        Like

Leave a comment