Updated on 2024-05-21 GMT+08:00

Introducing Consistency Levels

GaussDB(for MySQL) provides two consistency levels to meet requirements in different scenarios.

  • Eventual consistency (default)
  • Session consistency

Constraints

  • To configure consistency level, the kernel version of your GaussDB(for MySQL) instance must be 2.0.28.1 or later.
  • To use session consistency, the kernel version of your proxy instance must be 2.7.4.0 or later.

Eventual Consistency

After a proxy instance is created, requests for SELECT operations are routed to different nodes based on their read weights. Because there is a replication delay between the primary node and each read replica and the replication delay varies for different read replicas, the result returned by each SELECT statement may be different when you repeatedly execute a SELECT statement within a session. In this case, only eventual consistency is ensured.

Session Consistency

To eliminate data inconsistencies caused by eventual consistency, session consistency is provided. Session consistency ensures the result returned by each SELECT statement in a session is the data that was updated after the last write request.

Proxy instances record the log sequence number (LSN) of each node and session. When data in a session is updated, a proxy instance records the LSN of the primary node as a session LSN. When a read request arrives subsequently, the database proxy compares the session LSN with the LSN of each node and routes the request to a node whose LSN is at least equal to the session LSN. This ensures session consistency.

Figure 1 Principle of session consistency

In session consistency, if there is significant replication delay between the primary node and read replicas and the LSN of each read replica is smaller than the session LSN, requests for SELECT operations will be routed to the primary node. In this case, loads on the primary node are heavy and instance performance suffers.