PolarProxy serves as a proxy between a database and an application in a PolarDB cluster. PolarProxy receives and routes all the requests from the application. PolarProxy supports advanced features, such as automatic read/write splitting, load balancing, consistency levels, and connection pools. PolarProxy is easy to use and maintain, and provides high-availability and high-performance services. You can connect to PolarDB cluster endpoints to use the features of PolarProxy.
A PolarDB cluster of Cluster consists of a primary node and up to 15 read-only nodes. By default, PolarDB provides two types of endpoints: the primary endpoint and cluster endpoints. PolarProxy provides cluster endpoints for PolarDB. Cluster endpoints include read/write endpoints and read-only endpoints. Read/write endpoints support read/write splitting. Read-only endpoints allow PolarDB clusters to distribute read requests to read-only nodes based on the number of connections.
PolarProxy Enterprise Editions
- Standard Enterprise Edition is used by clusters of the General-purpose type of PolarDB for MySQL Cluster Edition, which shares CPU resources with smart elastic scaling within seconds provided based on business loads.
- Dedicated Enterprise Edition is used by clusters of the Dedicated type of PolarDB for MySQL Cluster Edition, which exclusively uses allocated CPU resources and provides better stability.
|Item||Standard Enterprise Edition||Dedicated Enterprise Edition|
Currently free of charge. In the future, when to charge the fees is to be determined.
|Resource type||Shared CPU physical resources with smart elastic scalability within seconds are provided based on business loads.||Exclusive use of physical resources with better performance stability provided.|
|Architecture||High-availability redundant architecture.|
|Cluster specifications||Minimum configuration: 2 cores.|
|Performance||Compared with previous editions, the maximum IOPS of cluster storage is increased by 50%. For more information about the maximum IOPS of different cluster specifications, see Specifications of compute nodes.|
|Read-only node specifications||The configurations are not necessarily consistent between the read-only nodes and the primary nodes. You can downgrade configurations based on business loads to save costs.|
|Number of read-only nodes||Up to 15 read-only nodes.|
|Endpoint||One primary endpoint and seven cluster endpoints.|
|Failover between the primary and read-only nodes||Connection and transaction not interrupted and brief block of 5 to 10 seconds.
This feature is expected to be available at the end of April 2022.
|Interruption protection (connection retention)||Supported.|
|Data masking (for security)||Supported.|
|Business stability during configuration change||Supported.|
|Multi-master architecture (available soon)||Supported.
For more information about the multi-master architecture, see Release announcements for the multi-master architecture.
|Compute node scale-out within seconds (available soon)||Supported.||Exclusive use of resources to ensure sufficient resources.|
|Proxy throttling protection (available soon)||Supported.
This feature is expected to be available at the end of May 2022.
At present, you can use PolarProxy Enterprise Edition free of charge. In the future, when to charge the fees is to be determined.
Edition switchover policies
The following table describes the edition switchover policies for PolarProxy Enterprise Edition.
||Single Node Edition and Archive Database Standalone Edition do not support the Database Proxy Enterprise Edition feature regardless of existing or newly purchased instances.|
||Newly purchased cluster||Newly purchased clusters only support PolarProxy Enterprise Edition.|
|Existing pay-as-you-go cluster||Existing pay-as-you-go clusters are automatically switched to PolarProxy Enterprise Edition.|
|Existing subscription cluster|
Only clusters of PolarDB Cluster Edition and Archive Database Cluster Edition support cluster endpoints and PolarProxy. PolarDB clusters of the Single Node and Archive Database (High Compression Ratio) editions use a single-node architecture, and do not support PolarProxy and cluster endpoints.
- PolarProxy does not support compression protocols for the default and custom cluster endpoints.
- If you do not enable the transaction splitting feature after cluster endpoints are used, all the requests in a transaction are forwarded to the primary node.
- When you execute the
SHOW PROCESSLISTstatement after cluster endpoints are used, the system returns the results of all the nodes.
- If you execute multi-statement or call stored procedures, all subsequent requests for the current connection are forwarded to the primary node. For more information, see Multi-Statement. To use the read/write splitting feature, you must close the current connection and reconnect to the cluster.
- The maximum number of connections to a PolarDB cluster endpoint depends on the specifications of compute nodes in backend databases. For a cluster endpoint that supports read/write splitting, an application establishes a connection to each compute node in the backend database. Therefore, the maximum number of connections that an application can use is the maximum number of connections of a single compute node. For a cluster endpoint that is in read-only mode, an application connection only establishes a connection to one compute node in the backend database. The maximum number of connections that an application can use is the sum of the maximum numbers of connections for all read-only nodes. For a cluster endpoint that is in read-only mode, you can use the Transaction-level connection pools feature to increase the maximum number of connections that an application can use.
- If a session that supports read/write splitting is created after you add or restart a read-only node, read requests are forwarded to the read-only node. If a session that supports read/write splitting is created before you add or restart a read-only node, read requests are not forwarded to the read-only node. To forward these read requests to the read-only node, you must close the connection and reconnect to the cluster. For example, you can restart your application to establish a new connection.
- Do not modify environment variables when you call stored procedures or execute multi-statement,
set names utf8mb4;select * from t1;. Otherwise, the data read from the primary node and read-only nodes is inconsistent.
PolarDB clusters of Cluster Edition support read/write splitting. This feature allows a PolarDB cluster to distribute read and write requests from applications by using a cluster endpoint. Write requests are forwarded to the primary node. Read requests are forwarded to the primary node or read-only nodes based on the loads on each node. The number of pending requests on a node indicates the loads on the node. For more information, see Read/write splitting.
- Primary Node Accepts Read Requests
SQL query statements are sent to read-only nodes when data consistency and transaction correctness are achieved. This reduces the loads on the primary node and makes the primary node stable. For more information, see Offload reads from the primary node.
- Transaction Splitting
PolarDB supports transaction splitting. This feature ensures data consistency in a session and allows PolarDB to send read requests to read-only nodes. This reduces the loads on the primary node. For more information, see Split transactions.
PolarDB asynchronously replicates the updates from the primary node to read-only nodes. In read/write splitting mode, a read request that follows a write request may fail to obtain the latest data. This causes data inconsistency. PolarDB provides the eventual consistency, session consistency, and global consistency options. For more information, see Consistency levels.
PolarDB supports session-level connection pools and transaction-level connection pools. You can select a connection pool based on your business requirements to reduce the database loads that are caused by a large number of connections. For more information, see Connection pools.
PolarDB supports the persistent connection feature to prevent transient disconnections or temporary failures in new connections. These issues can be caused by O&M operations, such as configuration upgrades, failover, and minor version upgrades. Issues can also be caused by other reasons. For example, the server on which nodes are deployed is unavailable. The persistent connection feature improves the high availability of PolarDB. For more information, see Persistent connections.
Dynamic data masking
When your application initiates a data query request, PolarDB masks the sensitive data that is queried before PolarDB returns the data to the application. To achieve this, you need to specify the database account, the database name, and the table or column that requires data masking before the data is queried. For more information, see Dynamic data masking.
Related API operations
|CreateDBEndpointAddress||Creates a public endpoint for a specified PolarDB cluster.|
|CreateDBClusterEndpoint||Creates a custom cluster endpoint for a specified PolarDB cluster.|
|DescribeDBClusterEndpoints||Queries the information about the endpoints of a specified PolarDB cluster.|
|ModifyDBClusterEndpoint||Modifies the configuration of a cluster endpoint for a specified PolarDB cluster.|
|ModifyDBEndpointAddress||Modifies the endpoints such as custom cluster endpoints of a specified PolarDB cluster.|
|DeleteDBEndpointAddress||Deletes a cluster endpoint of a specified PolarDB cluster. This operation cannot be used to delete private custom cluster endpoints.|
|DeleteDBClusterEndpoint||Deletes a custom cluster endpoint of a specified PolarDB cluster.|