PolarDB:What is a database proxy

Introduction to PolarDB PolarProxy

A PolarDB Cluster Edition cluster consists of multiple nodes, including one primary node and multiple read-only nodes. By default, the cluster provides two endpoints: a primary endpoint and a cluster endpoint. The cluster endpoint is provided by PolarDB PolarProxy and supports two modes: read/write (automatic read/write splitting) and read-only.

Support for Two Database Proxy Versions

Billing

Limits

Cluster endpoints and their related database proxy features are supported only by PolarDB Cluster Edition.

Notes

• The default cluster endpoint and custom cluster endpoints do not support the compression protocol.

• If you use a cluster endpoint without enabling transaction splitting, all requests within a transaction are routed to the primary node.

• When you run the SHOW PROCESSLIST command, the system merges and returns the results from all nodes.

• If you run a multi-statement or call a stored procedure, subsequent requests on the current connection are routed to the primary node. To restore read/write splitting, you must disconnect and then reconnect.

• The maximum number of connections for a PolarDB cluster endpoint is not limited by the endpoint itself. Instead, it is determined by the specifications of the backend compute nodes. For a read/write cluster endpoint, each application connection establishes a connection to every compute node in the backend database. Therefore, the maximum number of application connections is limited by the maximum number of connections supported by a single compute node. For a read-only cluster endpoint, each application connection establishes a connection to only one compute node in the backend database. Therefore, the maximum number of application connections is the sum of the maximum connections supported by all read-only nodes associated with that endpoint. For read/write cluster endpoints, you can use the transaction-level connection pooling feature to increase the maximum number of available connections for your application.

• After you add or restart a read-only node, new read/write splitting connections can forward requests to that node. However, existing connections cannot. To route requests from existing connections to the new or restarted node, you must disconnect and then reconnect. For example, you can restart your application.

• Do not modify environment variables, such as in set names utf8mb4;select * from t1;, while running multi-statements or calling stored procedures. Otherwise, data read from read-only nodes and the primary node may be inconsistent.

• When you use an application connection pool to establish a URL connection, add the connectTimeout and socketTimeout parameters to the URL. This helps prevent the application connection pool from hanging if packets are lost due to network issues or other unexpected events. For more information about the parameters, see Parameters. Example:

  Java URL: jdbc:mysql://ip:port/db?connectTimeout=60000&socketTimeout=300000

Upgrade database proxy specifications

The default specifications of PolarProxy Enterprise Edition are sufficient for most application scenarios. If you perform stress tests or if your service throughput is high, the latest version of the database proxy automatically scales its specifications in real time based on the proxy's load. This scaling prevents the database proxy from becoming a performance bottleneck. For older versions of the database proxy, you can also manually upgrade the specifications.

For more information, see Upgrade database proxy specifications.

Related API operations