- YugabyteDB YSQL
- After setting
yb_read_from_followersa read does not happen from the read replicas
- Performance of a read from a read replica node does not seem to reflect that of a local read
When the configuration parameter
yb_read_from_followers is set to true, the system allows read operations to be performed on follower replicas, depending on the nature of the transaction. However, this behavior is only applicable if the transaction is marked as read-only.
You can mark a transaction as read-only by applying the following guidelines:
SET TRANSACTION READ ONLYapplies only to the current transaction block.
SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLYapplies the read-only setting to all statements and transaction blocks that follow.
SET default_transaction_read_only = TRUEapplies the read-only setting to all statements and transaction blocks that follow.
You can read more about follower reads in YSQL here:
The primary objective of reading from followers is to offload read traffic from the leader replica, enabling better scalability and reducing the load on the leader. By allowing reads from followers, the system can distribute the read workload across multiple replicas, thereby improving overall performance.
In this scenario, the read operation is performed on the closest replica of the tablet, which could be either the leader or a follower. The selection of the closest replica is determined by factors such as network latency, availability, and load distribution. When the configuration parameter
yb_read_from_followers is set to false or the transaction/statement is not read-only, the system enforces that read operations occur exclusively from the leader replica.
Differences between YCQL and YSQL follower reads
The behavior in YCQL and YSQL diverges in the treatment of follower reads. In YCQL, setting a driver consistency level "ONE" or using a read replica is sufficient to get a follower read, without any other query level or session level variable.
In YSQL, follower reads requires a read only transaction. The implementation is intentional, to prevent data inconsistency issues where a local, potentially stale, read is used to insert data. You can imagine a transaction like the following
INSERT INTO TABLE1 (id, col_1, col_2)
SELECT id, 'data1', 'data2' FROM TABLE2
WHERE col_a = 'value';
If this query were executed on a node with follower reads enabled, or a read replica, and the
SELECT FROM TABLE2 was executed with a stale read (i.e. the value of
id had been updated where
col_a = 'value' ) , then the insert would also be stale or inconsistent.