Read consistency among many readers

[Bibek Shrestha]

Hi,

I've posted this question on StackOverflow as well (https://stackoverflow.com/questions/62661648/consistent-reads-from-multiple-readers)

I'm going to post it here too for visibility:

Consider a scenario, a web request makes N database requests. If I know that all or majority of the requests can be sent to db-readers. With Vitess's architecture, when there are multiple readers setup, wouldn't those N db requests get distributed to different db-readers?

When different readers have different replication lag, it is possible that N db requests result in inconsistent results.

Does Vitess have special ways of handling this?
Or how should an application deal with such a situation?

Would love to get some answers / insights on this situation.

--

Bibek Shrestha

[Claudio Martinez]

I was just researching this so I haven't had a chance to test this. I found that there's some control over how much replication lag is acceptable and how vitess reacts when all the servers are lagging, check the comments for FilterStatsByReplicationLag

If there's an edge case where you absolutely need the latest data, you can route some specific queries to the master with "use xxxxx@master".

--
You received this message because you are subscribed to the Google Groups "vitess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vitess+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vitess/CANL3wv97Ht9ywVDDRMuYTnVJy4wBNbkr50e%2BNBoV3Uast8fTVA%40mail.gmail.com.

[Sugu Sougoumarane]

Vitess now supports replica transactions. So, that's what I'd recommend you use if you want consistent reads from replicas. There's a longer answer below if you don't want to use transactions.

The general idea of a replica read is that it's a dirty read. Even if you hit the same replica, the data could have changed from the previous read.

The only difference is that time moves forward if you went back to the same replica.

In reality, this is not very different from cases where you read older data from a different replica. Essentially, you have to deal with the fact that two pieces of data you read are potentially inconsistent with each other.

In other words, if you wrote the application to tolerate inconsistency between two reads, that code would likely tolerate reads that go back in time also. But it all depends on the situation.

I'll post this on stackoverflow also.

To view this discussion on the web visit https://groups.google.com/d/msgid/vitess/CAFVG3qsBPJNxA_7qGDCO%3D%2B6cJa1dZYKBW3Ky1a46TgLKUtfbuw%40mail.gmail.com.