I have a Aurora PostgresSQL cluster with read replicas.
I want to find out (preferably in AWS docs) if it gives strong consistency for reads from RO replicas after writes or is it "eventually consistent" meaning that RO replicas can return stale data during ongoing replication?
Unfortunately, this is not super clear from the documentation.
What I have found here is:
As a result, all Aurora Replicas return the same data for query results with minimal replica lag.
This lag is usually much less than 100 milliseconds after the primary instance has written an update.
However, I am not sure how to interpret this - does it return always the same data at a cost of higher latency with an added replication lag or can it return stale data during the replication?
Also, I am not sure if it depends on the underlying DB engine (Postgres in my case).
It is asynchronous replication as written in the docs. This means that Aurora replicas can return old data even though the new one has already been written in the writer instance.
As already said, data from the reader node is considered as "eventually consistent" even though the reader node(s) and the R/W node both share the same managed storage. The reason for this eventual consistency is because the propagation of WAL logs to the buffer pool of the reader node(s) is asynchronous. I.e. the writer node doesn't wait for the reader node(s) to confirm that it has applied the WAL logs to its buffer pool before acknowledging the transaction to the client app. But this "eventual consistency" will only appear if the reader node happened to have data affected by those WAL logs in its buffer pool. Otherwise the reader node will read from the managed storage, which is always strongly consistent.
After some milliseconds, the reader nodes' buffer pool will anyway be updated.

If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With