Database proxy FAQ

Why can't I read data immediately after inserting it?

In a read/write splitting setup, write requests go to the primary node while read requests are distributed across read-only nodes. Replication between the primary and read-only nodes introduces latency, so a read issued immediately after a write may return stale data.

PolarDB handles this with session consistency: within the same session, reads always reflect your previous writes, regardless of replication latency. For details, see Session consistency.

Does PolarDB support zero-latency reads after writes?

Not through the cluster endpoint. Under normal load, replication latency between the primary node and read-only nodes is in the millisecond range, so read/write splitting endpoints cannot guarantee zero-latency reads immediately after writes.

To get zero-latency reads, send both reads and writes through the primary endpoint, which always points to the primary node. For instructions on finding the primary endpoint, see View endpoints and ports.

Why is the CPU load on the primary node high?

Cause: Several conditions can overload the primary node.

Check each of the following:

• Direct connection to the primary endpoint — If your application connects directly to the primary endpoint, all traffic hits the primary node. Switch to the proxy endpoint to enable read/write splitting.

• Write-heavy workload — If your workload has significantly more write requests than reads, the primary node naturally carries a heavy load.

• Primary node accepting read requests — If Primary Database Accepts Read Requests is set to Yes for the proxy endpoint, change it to No to offload read traffic from the primary node.

• ORM wrapping requests in transactions — Some ORMs wrap all requests in transactions by default, which routes everything to the primary node. Enable Transaction splitting on the proxy endpoint to route read-before-write requests in transactions to read-only nodes instead.

If you're running Sysbench stress tests, add --oltp-skip-trx=on (Sysbench 0.5) or --skip-trx=on (Sysbench 1.0) to disable transactions during the test. For more information, see Load balancing.

Why does one node receive more requests than others?

Requests are distributed based on current node load. Nodes with a lower load receive more traffic.

Are newly added read-only nodes automatically included in read/write splitting?

Yes. Newly added read-only nodes are automatically included in read/write splitting without any manual configuration.

Does switching to global consistency affect performance?

Yes. Global consistency (strong) introduces some performance overhead compared to session consistency (medium) and eventual consistency (weak). For high-concurrency workloads, change the consistency level during off-peak hours. For more information, see Global consistency.

What is the difference between Standard Enterprise Edition and Dedicated Enterprise Edition of PolarProxy Enterprise Edition?

Does removing a read-only node from a cluster endpoint affect active connections?

It depends on the endpoint mode:

• Read/write splitting mode — Active connections are disconnected only if the node has ongoing requests, transactions, or temporary tables. Otherwise, your applications are not affected.

• Read-only mode — All active connections to that endpoint are disconnected.

For more information, see Take a read-only node offline.

What read/write modes does PolarDB support?

PolarDB cluster and custom endpoints support two modes:

Changing the read/write mode affects only new connections. Existing connections continue to use the previous mode. For configuration details, see Configure database proxy.

Why does Binlog dump return an error about non-block mode?

Read-only endpoints using a connections-based load balancing policy do not support pulling binary logs (binlog) in non-block mode. To resolve this, go to the console and change the load balancing policy of the read-only endpoint to Active Request-based Load Balancing. For background on load balancing policies, see Load balancing.

What are the differences between database proxy versions 1.x.x and 2.x.x?

PolarDB for MySQL includes two major proxy versions:

Can I upgrade from proxy version 1.x.x to 2.x.x using a minor version upgrade in the console?

No. A minor version upgrade only upgrades your proxy to the latest release within the 1.x.x series. To move to 2.x.x, follow the steps in Upgrade database proxy version from 1.x.x to 2.x.x.

What are the requirements for upgrading from proxy version 1.x.x to 2.x.x?

Your cluster must meet the following minimum revision version requirements:

If your cluster meets these requirements, contact Alibaba Cloud support for assistance with the upgrade.

Is the database proxy automatically upgraded to 2.x.x during a major engine version upgrade?

Yes. The database proxy is automatically upgraded to 2.x.x during a major engine version upgrade. You cannot keep it at version 1.x.x.

Why do connection errors occur after setting a read-only node's weight to 0 and then removing it?

Scenario: You set a read-only node's read/write splitting weight to 0 to stop new traffic, then remove it from the cluster endpoint — but your application still reports connection errors.

Cause: The behavior depends on the load balancing policy of the cluster endpoint:

• Connections-based Load Balancing — Load balancing is only applied when a new connection is established. Existing connections remain pinned to the node even after its weight is set to 0. When you remove the node, those pinned connections break.

• Active Request-based Load Balancing — Setting a node's weight to 0 immediately stops all new requests from routing to that node, regardless of existing connections.

Solution: To safely remove a read-only node:

1. Change the Load Balancing Policy of the cluster endpoint to Active Request-based Load Balancing.

2. Set the read/write splitting weight of the node to 0.

3. Remove the read-only node.

Why does setting a read-only node's weight to 0 in a cluster endpoint and then removing it cause connection errors?

• Scenario: You want to remove a read-only node from a cluster endpoint. To prevent service disruptions, you first set the read/write splitting weight of the node to 0. You expect that new read requests are no longer sent to the node. However, your application still reports connection errors after you remove the node.

• Cause: Cluster endpoints support two Load Balancing Policy: Active Request-based Load Balancing and Connections-based Load Balancing.

  • Active Request-based Load Balancing: After you set the weight of a read-only node to 0, new requests are no longer routed to the node.

  • Connections-based Load Balancing: Load balancing is performed only when a connection is established. If a connection is already established with a read-only node, all subsequent requests over that connection are still sent to that node.

• Solution:

  1. Change the Load Balancing Policy of the cluster endpoint to Active Request-based Load Balancing.

  2. Set the read/write splitting weight of the read-only node that you want to remove to 0.

  3. Remove the read-only node.