Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

Aurora PostgreSQL meaning of the ReplicationLag metric

0

Hi, My company uses Aurora PostgreSQL as the database cluster and we want to leverage the fact that most of the traffic in our microservices are read-only queries and route "SELECT" statements to the reader endpoint. There is concerns about some background processes in our event driven architecture that "could" be reading stale data, and while we can handle this type of issues I would like to understand how the replication works specifically for the Postgres version of Aurora.

In one general document I can read that the cluster volume physically made up of multiple copies of the data for the DB cluster and:

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. Replica lag varies depending on the rate of database change. That is, during periods where a large amount of write operations occur for the database, you might see an increase in replica lag.

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html#Aurora.Replication.Replicas

If all the Read replicas and the Writer instance points to the same shared volume, would it still be possible to have lag?

Then, what's the meaning of the sentence?

Because Aurora Replicas read from the same cluster volume as the writer DB instance, the ReplicaLag metric has a different meaning for an Aurora PostgreSQL DB cluster. The ReplicaLag metric for an Aurora Replica indicates the lag for the page cache of the Aurora Replica compared to that of the writer DB instance.

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Replication.html#AuroraPostgreSQL.Replication.Monitoring

It really indicates that the data in my replica is lagging behind, or just the cache that is not replicated? In both cases, would I see stale data if a connection performs a SELECT on the data that is lagging/cache not updated?

Tags
Aurora PostgreSQL
Language
English

asked 2 years ago1.6K views

1 Answer
1
Accepted Answer

Your understanding of Aurora PostgreSQL's replication mechanism is on the right track, but let's clarify a few points to address your concerns about potential stale data.

In Aurora PostgreSQL, all instances (both the writer and the read replicas) indeed share the same underlying storage volume. This shared storage architecture is fundamental to Aurora's design and contributes to its high performance and low replication lag. However, it's still possible to have some lag, albeit minimal in most cases.

The ReplicaLag metric in Aurora PostgreSQL has a specific meaning that differs from traditional PostgreSQL replication. It doesn't indicate that the data in the replica is lagging behind in the traditional sense. Instead, it refers to the lag in the page cache of the Aurora Replica compared to the writer instance.

Here's what this means in practice:

  1. The underlying data in the shared storage is always up-to-date across all instances.
  2. Each instance (writer and replicas) maintains its own page cache in memory for faster data access.
  3. The ReplicaLag metric indicates how far behind a replica's page cache is compared to the writer's page cache.

In most cases, this lag is minimal (usually less than 100 milliseconds) and doesn't typically result in stale data being read. However, during periods of high write activity, you might see an increase in this lag.

When a connection performs a SELECT on a replica:

  1. If the data is already in the replica's page cache, it will be returned immediately.
  2. If the data is not in the cache, the replica will read from the shared storage, which always has the most up-to-date data.

This means that in the vast majority of cases, you won't see stale data when querying a replica, even if there is some reported ReplicaLag. The lag primarily affects the performance of reads that aren't cached, rather than the accuracy of the data.

However, in extremely rare cases during very high write loads, it's theoretically possible that a read could return slightly stale data if it reads from the cache before the cache is updated. This scenario is uncommon due to Aurora's efficient cache invalidation mechanisms.

For your event-driven architecture, the risk of reading stale data is very low. Nevertheless, if you have specific transactions that absolutely must read the most up-to-date data, you can direct those to the writer instance. For the majority of read-only queries, using the reader endpoint should provide excellent performance without significant concerns about data staleness.
Sources
Replication with Amazon Aurora PostgreSQL - Amazon Aurora
Replication with Amazon Aurora - Amazon Aurora
Replication with Amazon Aurora MySQL - Amazon Aurora

answered 2 years ago

EXPERT

reviewed 2 years ago

  • Will
    2 years ago

    Thank you very much.

    I accepted the answer before the Expert Review, but I am more at ease now that it was reviewed.

    Nonetheless, it confirmed my suspicions. I believe we will not have issues but in any case I am suggesting the developers to explicitly use the connection to the writer instance in case of any concern.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content