FAQ

Why can't I read a record immediately after inserting it?

PolarProxy replicates data from the primary node to read-only nodes with a small delay — typically a few milliseconds, even when the loads on the primary node and read-only nodes are not heavy. When you insert a record and immediately query it through a cluster endpoint with read/write splitting enabled, the query may land on a read-only node before replication completes.

PolarDB supports session consistency, which ensures that queries within the same session always reflect your latest writes. To eliminate the delay entirely, connect using the primary endpoint — this routes all requests to the primary node. For details, see .

Why do read-only nodes have low load even when the primary node is busy?

All statements within a transaction share the same underlying connection, which points to the primary node. This means that in workloads with many explicit transactions (using BEGIN/COMMIT), most requests route to the primary node — leaving read-only nodes underutilized.

To distribute load more evenly:

• For Sysbench stress tests: Skip the BEGIN/COMMIT statements by specifying --oltp-skip-trx=on (Sysbench 0.5) or --skip-trx=on (Sysbench 1.0).

• For production workloads with heavy transaction load: Enable the transaction splitting feature, which splits read statements out of transactions and routes them to read-only nodes. For details, see Transaction splitting.

Why does one node receive more requests than others?

Requests are distributed based on current load. Nodes with lighter loads receive more requests. This is expected behavior — uneven distribution reflects the load-balancing algorithm working as designed.

Does a new read-only node automatically receive read requests?

It depends on when the connection was established. Sessions created after you add the read-only node automatically receive read requests through that node. Sessions created before the node was added continue using the previous routing — they are unaware of the new node.

To route existing connections to the new node, close and reopen those connections. The simplest way is to restart your application, which forces all connections to reconnect.

Cluster endpoint limitations

Before managing cluster endpoints, be aware of these constraints:

A read-only node with a single-node cluster endpoint cannot automatically become the primary node after a failover. To make it the primary, promote it manually.

Can I modify or delete a cluster endpoint?

Both the default cluster endpoint and custom cluster endpoints can be modified. For details, see .

Only custom cluster endpoints can be deleted — the default cluster endpoint cannot be deleted. For details, see .

What happens to a single-node cluster endpoint during a failover?

A read-only node with a single-node cluster endpoint does not automatically become the new primary node after a failover. If you need the node to take over as the primary, promote it manually. For details, see Automatic failover and manual failover.