This topic covers frequently asked questions about the PolarDB database proxy.
Why can't I read data immediately after inserting it?
In a read/write splitting architecture, replication between the primary node and read-only nodes introduces latency. However, PolarDB supports session consistency, which guarantees that reads within the same session always reflect your previous writes. For more information, see Session consistency.
Does PolarDB support zero-latency reads after writes?
Under normal load, replication latency between the primary node and read-only nodes of a PolarDB cluster is in the millisecond range, so read/write splitting endpoints cannot guarantee zero-latency reads immediately after writes. If you require zero-latency reads, send both read and write requests through the primary endpoint, which always points to the PolarDB primary node. For instructions on how to view the primary endpoint, see View endpoints and ports.
Why is the CPU load on the primary node high?
High CPU load on the primary node can have multiple causes. Check each of the following:
If your application connects directly to the primary endpoint, check whether any services are configured to use the primary endpoint.
Your workload has significantly more write requests than read requests, which places heavy load on the primary node.
If Primary Node Accepts Read Requests is set to Yes for the proxy endpoint, change Primary Node Accepts Read Requests to No to stop routing read requests to the primary node.
Check whether Transaction Splitting is enabled for the proxy endpoint. Some ORMs wrap all requests in transactions by default, which routes everything to the primary node. Enable Transaction Splitting to route read-before-write requests in transactions to read-only nodes.
If you are 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 about load balancing strategies and transaction splitting, 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 requests.
Are newly added read-only nodes automatically included in read/write splitting?
Yes.
Does global consistency (strong) affect performance compared to eventual consistency (weak) and session consistency (medium)?
Global consistency (strong) introduces some performance overhead compared to eventual consistency (weak) and session consistency (medium). If your workload requires high concurrency, change the consistency level during off-peak hours.
What is the difference between Standard Enterprise Edition and Dedicated Enterprise Edition of PolarProxy Enterprise Edition?
Standard Enterprise Edition: Corresponds to the General-purpose cluster sub-edition. It shares physical CPU resources and provides intelligent, second-level elastic scaling based on workload.
Dedicated Enterprise Edition: Corresponds to the Dedicated cluster sub-edition. It uses exclusive physical CPU resources for enhanced performance stability.
Does removing a read-only node from a cluster endpoint affect active connections?
If you remove a read-only node from a read/write splitting cluster endpoint, active connections on that endpoint are disconnected only if the node has ongoing requests, transactions, or temporary tables. Otherwise, your applications are not affected.
If you remove a read-only node from a read-only cluster endpoint, all active connections on that endpoint are disconnected.
For more information about the impact of removing a read-only node, see Read-only node removal.
What read/write modes does PolarDB support?
Currently, PolarDB cluster and custom endpoints support two read/write modes: Read-only and Read/Write (automatic read/write splitting).
Read-only: All requests are routed to read-only (RO) nodes only. The read/write (RW) node cannot be attached to a read-only endpoint. Write attempts to a read-only endpoint return an error. This mode supports load balancing based on connection count and active request count.
Read/Write: Read/write splitting is automatically enabled. By default, the RW node is attached. This mode supports load balancing based on active request count only.
Changing the read/write mode affects only new connections. Existing connections continue to use the previous mode. For configuration details, see Configure PolarProxy.
Why does Binlog dump return an error "Connections-based load balancing policy does not support BINLOG_DUMP in non-block mode"?
Read-only endpoints that use a Load balancing connections-based load balancing policy do not support pulling Binlog files in non-block mode. In the console, change the load balancing policy of the read-only endpoint to active request-based load balancing.
How are database proxy versions 1.x.x and 2.x.x determined?
Currently, the PolarDB for MySQL database proxy has two major versions: 1.x.x and 2.x.x. The differences are as follows:
1.x.x
For clusters created before February 1, 2021. This version no longer receives new features and only receives bug fixes.
2.x.x
For clusters created on or after February 1, 2021. This is the current mainstream version. All new features are developed on this version, including persistent connections and data masking.
Can I upgrade the database proxy from 1.x.x to 2.x.x through a minor version upgrade in the console?
No. The proxy version 1.x.x can only be upgraded to the latest version within the 1.x.x series. It cannot be upgraded directly to 2.x.x. To upgrade to 2.x.x, see Can I upgrade the database proxy from 1.x.x to 2.x.x?.
Can I upgrade the database proxy from 1.x.x to 2.x.x?
Yes, but your cluster must meet the following requirements:
If your cluster runs PolarDB for MySQL 8.0.2, no minimum revision version is required.
If your cluster runs PolarDB for MySQL 8.0.1, the revision version must be 8.0.1.1.10 or later.
If your cluster runs PolarDB for MySQL 5.7, the revision version must be 5.7.1.0.6 or later.
If your cluster runs PolarDB for MySQL 5.6, the revision version must be 5.6.1.0.24 or later.
If your cluster meets the preceding requirements, contact us for assistance with the upgrade.
Is the database proxy automatically upgraded to 2.x.x during a major engine version upgrade?
Yes. During a major engine version upgrade, the database proxy is automatically upgraded to version 2.x.x. 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 from the cluster endpoint?
Scenario: You want to remove a read-only node from a cluster endpoint. To prevent impact on connections to that node, you first set its read/write splitting weight to 0. You expect that new read requests are no longer routed to the node. However, after you remove the node, your application reports connection errors.
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 that node.
Connections-based Load Balancing: Load balancing is performed only when a connection is established. If an existing connection is already routed to a read-only node, all subsequent requests over that connection continue to be sent to that node.
Solution:
Change the Load Balancing Policy of the cluster endpoint to Active Request-based Load Balancing.
Set the read/write splitting weight of the target read-only node to 0.
Remove the read-only node.