Replica set r/w defaults

[Serhat Şevki Dinçer]

Hi,
I think replica sets should have these as defaults:

Read: secondaryPreferred
Write concern: 2

What do you think ?

[Asya Kamsky]

I think it's 100% correct to have read preference primary only.   Always.

If anyone wants something other than primary they should explicitly specify it themselves.  SecondaryPreferred is a poor default, since applications will generally expect the data they just wrote to be available for reads, and this reduces the chances of that.

But it's certainly reasonable to have writeConcern majority as the default (I don't like 2, because 2 is only majority if you have 3 replica voting members, and majority would be more generally applicable to any size of replica set).

Asya

  

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/33a48d8b-96ba-4437-b1d3-48a0a6a0e849%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Serhat Şevki Dinçer]

I meant to consider these options together:
With secondaryPreffered alone, like you said, you cant immediately read what you just wrote most of the time.
Say for example, on average your writes will not be available for reading for 2 seconds (that is, there is a 2 seconds lag on average).
If you "also" use w:2 (or w:majority), then this lag will decrease, say 0.4 seconds: after a successful write, there is a good chance that a secondary will have that recent write, hence serve uptodate reads. The cost is write ops will take longer.

For a replica set, I think these options together make good sense, dont they ;?

The app programmer should accept this lag of course & develop accordingly.

[Max Schireson]

Your last sentence is important.

In my opinion application development is hard enough and we should be doing everything we can to make it easier so I look skeptically at anything that makes it harder. If you as an application developer can cope with not seeing writes immediately then reads from secondaries can increase efficiency, but imho that should be an opt-in not a default behavior.

-- Max

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/18b7dab1-7bb2-444a-ac1f-8df6fa7d10c1%40googlegroups.com.

[Asya Kamsky]

On top of what Max said about making developer's life easier so they make fewer mistakes, why would you *want* to read from a secondary by default - approximately half of them will *not* have the data even if you always wait for majority writeConcern, and you can't use secondary reads to scale, so I'm really unclear on why OLTP-ish type of application would want to read from anywhere except the primary.

Asya

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/18b7dab1-7bb2-444a-ac1f-8df6fa7d10c1%40googlegroups.com.

[Serhat Şevki Dinçer]

Hi Asya,
Can you elaborate on "secondaries do not help scale reads" ?

For example lets have a replica set of P,S,S. Can you show us emprical numbers for a scenario where we have multiple clients reading & writing, comparing these options seperately on the same read/write load:
- reads only from primary
- secondaryPreffered
- secondaryPreffered & w:2

Avg time of a client to read, avg time of a client to write, lag of just-written data, etc statistics would be great to better understand what's happening.

lag=0 for the 1st option set, so lets see how these stats come out. I'm curious, I have not done this experiment myself.

Thanks..

[Asya Kamsky]

You can read my thoughts about this here:  http://askasya.com/post/canreplicashelpscaling

TL;DR even if reading from secondary in your P,S,S scenario did help, you would then be giving up high availability for higher capacity.   You want to be able to support the load the cluster is taking even when some of your machines are down.   I don't believe it can help much because the data is the same on each node in a replica set.  

Use sharding for scaling.  Replication is for high availability via automatic failover.

Asya

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/4adebed9-a918-445e-8215-6193e528b2f3%40googlegroups.com.

[Serhat Sevki Dincer]

Hi Asya,
I read that & agree somehow with HA point but I think you are missing the point of having "multiple" clients.

A single user reading 100 mb/s and 4 users each reading 25 mb/s are two different loads, the second allowing the opportunity of parallel serving.

Lets have four clients, each reading & writing 25 mb/s from/to our PSS replica.

Primary-only read:
P needs to handle: 100 mb/s read, 100 mb/s write, forwarding writes to secondaries
S: 100 mb/s write

SecondaryPreferred:
P: 100 mb/s write, forwarding writes to secondaries
S: 100 mb/s write, 50 mb/s read

The load is definitely more balanced in the latter case. Now let's kill one server of the replica set:

Primary-only read:
P: 100 mb/s read, 100 mb/s write, forwarding writes to secondary
S: 100 mb/s write

SecondaryPreferred:
P: 100 mb/s write, forwarding writes to secondary
S: 100 mb/s write, 100 mb/s read

The load is still more balanced. Also "max-loaded server" of our replica set is always less loaded with the secondaryPrefered option. Therefore I fail to see why primary-only reads offer more availability :/

15 Eyl 2015 19:30 tarihinde "Asya Kamsky" <as...@mongodb.com> yazdı:

> You received this message because you are subscribed to a topic in the Google Groups "mongodb-user" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/mongodb-user/NC4k5IdKi2I/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to mongodb-user...@googlegroups.com.

> To post to this group, send email to mongod...@googlegroups.com.
> Visit this group at http://groups.google.com/group/mongodb-user.

> To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/CAOe6dJA7P39qnoeuEgo5%3D4H2a5iyvSGJ_O3mzA5N5ELGmWJ%3D6Q%40mail.gmail.com.