4 ms·
> 1. Writes can be lost if the primary dies and a secondary is promoted before data from primary has been replicated to it. Is this any different than how thin
by a13n 6y ago
> 1. Writes can be lost if the primary dies and a secondary is promoted before data from primary has been replicated to it.
Is this any different than how things work in eg Postgres?
> 2. The whole point of adding secondaries — again, the "webscale!" argument — is to scale read capacities
The main driver behind secondaries is redundancy/durability. If the primary goes down, there's no/very little overall service interruption.
If you need the latest data, read from the primary. If you care more about faster reads than perfect data accuracy, read from a secondary.
- pritambaral 6y ago>> 1. Writes can be lost if the primary dies and a secondary is promoted before data from primary has been replicated to it. > Is this any different than how things work in eg Postgres? 1. The comment of mine you are replying to applies to any DB that uses Eventual Consistency, as can be seen above it. 2. Yes, this is different in PG simply because PG doesn't do Eventual Consistency by default. >> 2. The whole point of adding secondaries — again, the "webscale!" argument — is to scale read capacities > The main driver behind secondaries is redundancy/durability. In general, maybe — or even maybe in your specific use-cases. But Mongo's prescribed use-cases — the ones they marketed, heavily, even going so far as to make up terms like "webscale" — are about 'performance' and 'scale'. I specifically call this out in my comment.