If your primary ApsaraDB RDS for MySQL instance is heavily loaded or your workloads require the capability to prevent transient connections that are caused by O&M operations such as switchovers, you can use the database proxy feature of ApsaraDB RDS for MySQL. This feature provides the read/write splitting capability to balance loads and reduce the CPU loads on your primary RDS instance. This feature also provides persistent connections to prevent transient connections and SSL encryption to improve the availability and security of the RDS instance.
A database proxy serves as a network proxy that resides between your database system and your application and receives all requests from your application. You can connect to your RDS instance by using a database proxy endpoint to use various capabilities of the database proxy feature. This simplifies the connection management of the RDS instance. The database proxy feature is easy to use and maintain and delivers high availability and high performance.
Scenarios
Read/write splitting is required.
The capability to prevent transient connections that are caused by O&M operations such as instance switchovers or failovers is required.
The primary RDS instance is heavily loaded due to a large number of requests that are encapsulated in transactions.
The primary RDS instance is heavily loaded due to an excessively large number of connections.
Most of your workloads require short-lived connections.
Read-only workloads and workloads that require isolation need to be processed.
NoteFor example, your database system consists of one primary RDS instance and four read-only RDS instances, and you have two applications, Application A and Application B. Application A initiates only read requests, and Application B initiates both read and write requests. You want to connect Application A and Application B to the database system. You can bind two read-only RDS instances to Proxy Terminal A that has the Read-only attribute to process the requests from Application A and bind the primary RDS instance and the other two read-only RDS instances to Proxy Terminal B that has the Read/Write attribute to process the requests from Application B. This way, Application A and Application B are physically isolated from each other in your database system.
Terms
database proxy endpoint (formerly known as proxy terminal)
Database proxy endpoints are the core of database proxies. You can configure connection settings for a database proxy endpoint based on your business requirements and modify the prefix and port number of the database proxy endpoint. If you use a database proxy endpoint to connect to an RDS instance, you can use the advanced capabilities of the database proxy feature.
Each RDS instance for which the database proxy feature is enabled supports up to seven database proxy endpoints. You can apply for one internal endpoint and one public endpoint for each database proxy endpoint. You can also configure connection settings for each database proxy endpoint to meet different business requirements and improve service flexibility. For more information, see Configure the connection settings for a database proxy endpoint and Database connection.
read/write splitting
Read/write splitting indicates that database proxy endpoints can be used to automatically forward read and write requests.
If your database system receives a large number of read requests and a small number of write requests, the primary RDS instance may fail to efficiently process read requests and your workloads may be interrupted. The read/write splitting feature allows the system to forward write requests to the primary RDS instance and read requests to the read-only RDS instances. This reduces the loads on the primary RDS instance. For more information, see What is read/write splitting?
persistent connections
Persistent connections are provided by the database proxy feature of ApsaraDB RDS for MySQL. If O&M operations that trigger switchovers are performed on the RDS instance, persistent connections help ensure that the connections between applications and database proxies of the RDS instance are kept alive. In this case, if you use database proxy endpoints to connect your applications to your RDS instance, disconnection errors are not reported. For more information, see Configure persistent connection settings.
transaction splitting
The transaction splitting feature is automatically enabled for a database proxy. This feature allows the system to forward the read requests prior to write operations in a transaction to the read-only RDS instances of your database system. This reduces the loads on the primary RDS instance. For more information, see Transaction splitting.
connection pooling
The connection pooling feature effectively resolves the issue of heavy instance loads caused by frequent new connections or excessive short-lived connections such as short-lived connections over PHP. For more information, see Set the connection pool type.
zone
The zone in which the proxy node and the database proxy endpoint resides. We recommend that the database proxy, database proxy endpoint, and RDS instance reside in the same zone to reduce the latency caused by cross-zone access. After you enable the database proxy feature, you can migrate the database proxy across zones. For more information, see Migrate proxy nodes across zones.
nearest access
If you deploy the database proxy of an RDS instance in multiple zones, you can enable the nearest access feature to connect your application to a proxy node that is deployed in the same zone as the application. In this case, the application, the proxy node, and the read-only RDS instance are in the same zone. This significantly reduces network latency. For more information, see Configure the nearest access feature.
SSL encryption
The SSL encryption feature can be enabled for a database proxy endpoint to protect data transmission. For more information, see Configure SSL encryption for a dedicated proxy endpoint.
Proxy deployment
The database proxy supports dual-zone deployment and single-zone deployment.
Single-zone deployment: All proxy nodes are deployed in the same zone.
Dual-zone deployment: Proxy nodes are deployed in two zones to implement cross-zone disaster recovery. No additional fees are generated.
Deployment modes
The following deployment modes are supported.
Deployment mode 1
Deployment mode 2
Deployment mode 3
Deployment mode | Zone | Total number of proxy nodes | Specification limit | Supported proxy type |
Deployment mode 1 | Two zones | 4 | The specifications of proxy nodes in the same zone must be the same. | Dedicated |
Deployment mode 2 | Two zones | 2 | The specifications of the proxy nodes must be the same. | Dedicated and general-purpose |
Deployment mode 3 | Single zone | 2 | The specifications of proxy nodes in the same zone must be the same. | Dedicated and general-purpose |
After you enable the database proxy feature, you can change the deployment mode of the database proxy. For more information, see Modify database proxy configurations.
Default mode and zones
The following table describes the default mode and zones for the database proxy.
RDS instance deployment | Database proxy type | Default deployment mode of the database proxy | Default zone of the database proxy |
Single-zone deployment | Dedicated | Deployment mode 3 | The default zone is the same as the zone of the primary RDS instance. |
General-purpose | Deployment mode 3 | ||
Dual-zone deployment | Dedicated | Deployment mode 1 |
|
General-purpose | Deployment mode 2 |
Disaster recovery of the database proxy
Deployment mode 1
When a proxy node-level fault occurs, the faulty node no longer processes business traffic, and the traffic is routed to normal proxy nodes in the same zone.
When a zone-level fault occurs, dual-zone deployment provides cross-zone disaster recovery capabilities. In this case, business traffic is routed to the proxy nodes in the normal zone. After the proxy node in the faulty zone recovers, new business traffic is routed to the recovered proxy node. The routing of existing persistent connections remains unchanged and automatically expires.
NoteIf you enable the nearest access feature and a zone-level fault occurs, the feature may become unavailable because service availability is prioritized over access latency. This ensures the availability of the database proxy.
Deployment mode 2
In this deployment mode, two proxy nodes are deployed in two zones. A proxy node-level fault is equivalent to a zone-level fault. When a fault occurs, business traffic is routed to a proxy node in another zone.
Deployment mode 3
When a proxy node-level fault occurs, the faulty node no longer processes business traffic, and the traffic is routed to another proxy node in the same zone.
When a zone-level fault occurs, the database proxy cannot provide services. You must wait for the zone to recover from the fault or manually change the deployment mode of the database proxy.
Database proxy types
ApsaraDB RDS for MySQL provides general-purpose and dedicated database proxies.
General-purpose: Database proxies share physical CPU resources and are provided free of charge. This type of database proxy is cost-effective.
Dedicated: Database proxies exclusively occupy the allocated physical CPU resources and are charged based on the pay-as-you-go billing method. This type of database proxy delivers stable performance.
The following table describes the differences between the two types of database proxies.
Item | General-purpose | Dedicated |
Billing method | Free of charge. | Pay-as-you-go. For more information, see Billing rules for database proxies. |
Resource type | Physical CPU resources are shared. | Physical CPU resources are exclusively occupied to deliver high performance and stability. |
Specification range for a single proxy node | 1 to 8 CPU cores. | 1 to 16 CPU cores. |
RDS instance | RDS instances on RDS High-availability and RDS Cluster Edition | |
Deployment mode | Deployment modes 2 and 3 are supported. For more information, see Proxy deployment. | Deployment modes 1, 2, and 3 are supported. For more information, see Proxy deployment. |
Single-zone deployment | Supported. | |
Dual-zone deployment | Supported. | |
Nearest access | Unsupported. | Supported. |
Read/write splitting | Supported. | |
Transaction splitting | Supported. | |
Proxy endpoint (formerly proxy terminal) | Each RDS instance for which the database proxy feature is enabled supports up to seven database proxy endpoints. You can apply for one internal endpoint and one public endpoint for each database proxy endpoint. | |
Persistent connections during switchovers | Supported. | Supported. |
Persistent connections during failovers | Unsupported. | Supported. |
Connection pooling | Supported. | |
SSL encryption | Supported. |
Relationship between the specification of the database proxy and the specifications of proxy nodes:
Specification of a database proxy = Specifications of all proxy nodes
. For example, four dedicated database proxy nodes are deployed in Zone A and Zone B, the number of proxy nodes in each zone is 2, and the number of CPU cores for a single proxy node is 1 in Zone A and is 2 in Zone B.The specification for the database proxy equals the specifications of the proxy zones
. In this example, the specification for the database proxy is 6 CPU cores. The value is obtained based on the following calculation: 1 × 2 + 2 × 2 = 6.Relationship between the number of proxy nodes and the specification of the database proxy:
Number of proxy nodes = Specifications of the database proxy/Unit specification of a proxy node
. The unit specification of a proxy node is fixed as 2 CPU cores. For example, if the specification of the database proxy is 6 CPU cores, the number of proxy nodes is 3. The value is obtained based on the following calculation:6/2 = 3
.
Usage notes
For more information, see Usage notes of database proxies.
Billing rules
For more information, see Billing rules for database proxies.
References
For more information, see Use the database proxy feature.