Read Preference of Event Consumer

[aisven]

It would be nice to have the choice of MongoDB read preference at the event consumer side to achieve some serious load balancing.

Using the casbah driver we are interested in Secondary and SecondaryPreferred:
http://mongodb.github.io/casbah/api/index.html#com.mongodb.casbah.ReadPreference$

Is there already a way to configure akka-persistence-mongo to achieve this with casbah and ReactiveMongo drivers?

Are there any serious arguments against using a read preference with reads across MongoDB replicas? If one replica already has some events, and the other does not, this could perhaps disrupt a particular consumer actor in some way.

[scullxbones]

Sure I think that's doable. It should be a fairly small change to both drivers. If you want to use replica sets, you should also use the Majority write concern instead of simply Journaled.

After reading a couple of aphyr's posts on MongoDB, I have taken a step back on the product that I work on in my day job as far as horizontally scaling mongo to rethink things. They're worth looking at if you're considering reading from slaves, or even just using MongoDB in general. I'd take them as serious arguments against taking MongoDB horizontal, at least until the Mongo team shores up replication. I know that's an HA trade-off, but from what aphyr found that HA may be purely theoretical, especially during a partition event.

https://aphyr.com/posts/284-call-me-maybe-mongodb
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads

[aisven]

Thanks, that got me thinking.

For event sourcing and CQRS we use some constraints at application level that simplify things:

• serialize processing of commands on the entity
• validate each command against the current in-memory entity state
• derive event(s) from the command and append event(s) to the event history of the entity
• event history per entity
• never update any event
• quarantine the entity if an event cannot be written
• UUID type 4 random as entity ID

Question is if even so, for the write side of CQRS+ES, some of aphyr's observations still might imply event loss under horizontal scaling of MongoDB, even when using Majority write concern and Primary read concern and with a current MongoDB version.

[aisven]

After watching aphyr's talk http://www.ustream.tv/recorded/61443262 I think the answer is yes. During a network partition situation with two active primaries events can be lost when the degenerate primary finally resides and its recorded data is discarded by MongoDB.