Follower reads
When applications run in multiple regions, they incur cross-region latency to read the latest data from the leader, even though there could be a follower present locally. This is because all followers may not have the latest data at the read time.
In some scenarios, however, reading from the leader is not necessary. For example:
- The data does not change often (for example, movie database).
- The application does not need the latest data (for example, yesterday's report).
If a little staleness for reads is acceptable for the application running in other regions, then Follower Reads is the pattern to adopt.
Setup
Local
YB Managed
YB Anywhere
Setup
To set up a local universe, refer to Set up a local YugabyteDB universe.Setup
To set up a cluster, refer to Set up a YugabyteDB Aeon cluster.Setup
To set up a universe, refer to Set up a YugabyteDB Anywhere universe.Suppose you have a Global Database set up across 3 regions us-east, us-central, and us-west, with leader preference set to us-east. Suppose further that you want to run applications in all 3 regions. Read latencies would be similar to the following illustration.
Follower reads
Enable follower reads for your application using the following statements:
SET session characteristics as transaction read only;
SET yb_read_from_followers = true;
This allows the application to read data from the closest follower (or leader).
In this scenario, the read latency for the application in us-west drops drastically to 2 ms from the initial 60 ms, and the read latency of the application in us-central also drops to 2 ms.
As replicas may not be up-to-date (by design), this might return slightly stale data (the default staleness is 30 seconds). This is the case even if the read goes to a leader.
You can change the staleness value using the following YSQL configuration parameter:
SET yb_follower_read_staleness_ms = 10000; -- 10s
Although the default is recommended, you can set the staleness to a shorter value. The tradeoff is the shorter the staleness, the more likely some reads may be redirected to the leader if the follower isn't sufficiently caught up. You shouldn't set yb_follower_read_staleness_ms to less than 2x the raft_heartbeat_interval_ms (which by default is 500 ms).
Failover
When the follower in a region fails, the application redirects its reads to the next closest follower/leader.
Notice how the application in us-west reads from the follower in us-central when the follower in us-west has failed. The read latency is 40 ms, still much less than the original 60 ms.