All Products
Search

This Product

    ApsaraDB RDS:Database proxy FAQ

    Document Center

    ApsaraDB RDS:Database proxy FAQ

    Last Updated:Aug 26, 2026

    This topic addresses common questions and issues about using the database proxy for RDS for MySQL.

    Contents

    What is a database proxy?

    A database proxy is a network proxy service that sits between your database and application servers. It forwards all requests from your application to the database and provides advanced features such as automatic read/write splitting, transaction splitting, connection pools, and connection persistence. It is designed for high availability, high performance, and ease of use and maintenance.

    What is the difference between general-purpose and dedicated proxies?

    • general-purpose: Shares physical CPU resources, which makes it a cost-effective option. The maximum proxy specification is 16 CPU cores (8 proxy nodes), and this type is free of charge.

    • dedicated: Uses exclusive physical CPU resources, providing greater performance stability. The maximum proxy specification is 64 CPU cores (32 proxy nodes), and this type is billed on a pay-as-you-go basis.

    For more information, see General-purpose and dedicated proxies, Relationship between the number of proxy nodes and proxy specification, and Database proxy fees.

    Does a database proxy use the QPS or TPS of the primary instance?

    No.

    Is a database proxy endpoint the same as a regular instance endpoint?

    No.

    • A regular instance endpoint routes all requests to that specific instance.

    • A database proxy endpoint automatically identifies read and write requests based on your SQL statements. It forwards write requests to the primary instance and read requests to read-only instances. This process enables read/write splitting and reduces the load on the primary instance.

    After I enable the database proxy, are the original endpoints of the primary and read-only instances reclaimed?

    No.

    Is the internal network type of a database proxy the same as that of the primary instance?

    The internal network for a database proxy is always a VPC.

    What architecture do database proxies use? Is failover supported?

    The database proxy uses a highly available dual-primary-node architecture. Traffic is distributed between the two nodes in a 1:1 ratio. If one node fails, the other node takes over all the traffic. A task is automatically triggered to rebuild the failed node to maintain high availability.

    For more information about the deployment architecture, see Proxy deployment architecture.

    Relationship between proxy and node specifications

    proxy specification = Sum of all proxy node specifications

    For example, a dedicated proxy is deployed in a dual-zone deployment (Availability Zone A and Availability Zone B). In Availability Zone A, there are two proxy nodes, and the proxy node specification for each is 1 CPU core. In Availability Zone B, there are two proxy nodes, and the proxy node specification for each is 2 CPU cores. The total proxy specification is calculated as follows: (1 CPU core × 2) + (2 CPU cores × 2) = 2 CPU cores + 4 CPU cores = 6 CPU cores.

    Relationship between proxy nodes and specification

    number of proxy nodes = proxy specification / Specification per Unit, where the specification per unit is fixed at 2 CPU cores.

    For example, if the proxy specification is 6 CPU cores, the number of proxy nodes is 3 (6 / 2).

    Proxy node specification limits

    • The specification of a single proxy node ranges from 1 to 8 CPU cores for the general-purpose type and 1 to 16 CPU cores for the dedicated type.

    • All proxy nodes within the same availability zone must have the same specification.

    • In a dual-zone deployment with two nodes, both nodes must have the same specification.

    • Proxy nodes in different availability zones can have different specifications. For general-purpose proxies, we recommend that proxy nodes in different availability zones use the same specification.

    Relationship between proxy nodes and endpoints

    No.

    After you enable the database proxy for an RDS instance, you can create one to seven proxy endpoints. For each proxy endpoint, you can create one internal endpoint and one public endpoint. For more information, see Add a proxy endpoint.

    Does adding proxy endpoints improve performance?

    No.

    The performance of a database proxy depends on the number of read-only instances and the number of proxy nodes (proxy specification) for RDS High-availability Edition instances. For RDS Cluster Edition instances, the performance depends on the number of secondary instances and the number of proxy nodes (proxy specification).

    • Increasing the number of read-only instances (for High-availability Edition) or secondary instances (for Cluster Edition) improves the read-processing capacity of the database proxy.

    • Increasing the number of proxy nodes (proxy specification) improves the overall performance of the database proxy.

    Database proxy connection limits

    The database proxy does not limit the maximum number of connections. The specifications of your database's compute nodes determine this limit.

    Handling connection timeout errors

    Increase the value of the wait_timeout parameter and try connecting again. For more information about how to modify instance parameters, see Set the parameters of an ApsaraDB RDS for MySQL instance.

    Modifying a proxy endpoint

    Yes.

    You can modify a database proxy endpoint (read/write splitting endpoint). For more information, see Modify a proxy endpoint.

    Sending read requests to the primary instance

    Yes.

    You can assign a read weight to the primary instance when you configure the read weight distribution. For more information about how to assign a read weight to the primary instance, see Enable the database proxy feature for an ApsaraDB RDS for MySQL instance.

    Hint support for read/write splitting

    Yes. You can use a hint to force a request to be executed on the primary instance. For more information about the hint formats that are supported by RDS read/write splitting, see the "Use a hint to specify whether to send an SQL statement to a primary or read-only instance" section of Default read weight allocation rules.

    Modified read weights not taking effect

    After you modify read weights, only new connections are distributed based on the new weights. Existing connections are not affected.

    Load imbalance with read weights

    If the load distribution across nodes does not match the configured read weights, check the following:

    • Check if your requests are part of a transaction. All requests within a transaction are routed to the primary instance. You can enable transaction splitting to reduce the load on the primary instance.

    • Ensure you are connecting exclusively through a database proxy endpoint. Connections made using the primary or read-only instance endpoints bypass read weight distribution.

    Configuring read weights without a database proxy

    If the database proxy is disabled, you cannot configure read weights for read-only instances. However, you can still achieve read/write splitting and load balancing by using the separate endpoints for the primary and read-only instances in your application code.

    Connection failover for unavailable read-only instances

    No, existing connections to the failed instance do not automatically fail over. A new connection is established to a healthy instance only after the failed connection times out.

    How do you verify read/write splitting after you enable the database proxy service?

    See Verify read/write splitting.

    Automatic data synchronization to new read-only instances

    Yes. When you enable the database proxy for read/write splitting, historical data is automatically synchronized from the primary to the read-only instance. No manual intervention is required.

    Proxy connection pool vs. application connection pool

    The database proxy provides a proxy-level connection pool that is independent of your application's client-level pool. If your application already uses a connection pool, using the proxy's connection pool is unnecessary. For more information about the connection pool of the database proxy, see Configure a connection pool.

    Handling garbled characters in query results

    Run the following command to check whether the character sets used by the primary instance and read-only instances are consistent:

    select 
@@global.character_set_results, 
@@global.character_set_client, 
@@global.character_set_connection, 
@@global.character_set_server;

    If the character sets are inconsistent, garbled characters may appear. You can modify the character set of the primary instance or a read-only instance to ensure that they are consistent. For more information about how to modify instance character sets, see Character sets of ApsaraDB RDS for MySQL instances.

    Automatic DDL synchronization

    Yes. All DDL operations, such as creating or deleting databases and tables, altering table structures, and modifying permissions, are automatically synchronized from the primary instance to its secondary instances.

    Viewing the VPC and vSwitch ID

    On the Database proxy page of your instance, go to the Connection information section. To view the information, hover the pointer over the icon to the right of the Port, as shown in the following figure.

    Impact of cross-zone migration on the primary instance

    Migrating proxy nodes across availability zones affects only workloads that use a database proxy endpoint. Connections made through the primary instance endpoint, a read-only instance endpoint, a cluster read/write endpoint, a cluster read-only endpoint, or a node-level endpoint are not affected. To minimize impact, switch your workloads to an unaffected endpoint and perform the migration during off-peak hours.

    Impact of cross-zone proxy migration

    When you migrate a proxy across availability zones, connections that use the database proxy may experience a transient disconnection that lasts about 30 seconds. The actual duration of the impact depends on your workload. To minimize impact, switch your workloads to an unaffected endpoint and perform the migration during off-peak hours. For more information, see Migrate database proxies across zones.

    Impact of cross-zone migration on nearest access

    It might become unavailable.

    Cross-zone migration may invalidate the nearest access configuration. After migration, the new zone is accessible by default; the original zone is no longer accessible. If a proxy endpoint zone differs from the new default zone, nearest access to that zone fails.

    Scenario Original proxy node zone Proxy endpoint Original nearest access New proxy node zone New default zone New proxy endpoint zone New nearest access
    Scenario 1: Zone A+Zone B → Zone A+Zone C Zone A Proxy endpoint a Zone A Zone A Zone A Zone A Zone A
    Zone C Invalid
    Zone B Proxy endpoint b Zone B Zone C Zone C Zone C Zone C
    Zone D Invalid
    Scenario 2: Zone A+Zone B → Zone C+Zone D Zone A Proxy endpoint a Zone A Zone C Zone C Zone C Zone C
    Zone E Invalid
    Zone B Proxy endpoint b Zone B Zone D Zone D Zone D Zone D
    Zone E Invalid

    Changing the availability zone during configuration

    No.

    If you need to migrate to a different availability zone, see Migrate database proxies across zones.

    Resolving vSwitchId error in single-zone deployment

    When changing from a dual-zone deployment (for example, in Availability Zone 1 and Availability Zone 2) to a single-zone deployment (for example, in Availability Zone 1), you must first delete the database proxy endpoint in Availability Zone 2. For more information, see Modify a proxy endpoint.

    Are resolved proxy IP addresses fixed?

    No. Always use the database proxy endpoint (for example, d3pswqe3jk9xwc5d****-rw4rm.rwlb.rds.aliyuncs.com) to connect, not the resolved IP address.

    Verifying connections through a proxy endpoint

    You can identify the connection method by the session ID. A session ID less than 16777215 indicates a connection through an instance endpoint. A higher ID indicates a connection through a database proxy endpoint.

    Session IDs are visible in Session management.

    Data not immediately visible after writes

    Common cause: This occurs when the proxy routes your read request to a read-only instance that is lagging behind the primary instance due to replication delay.

    Solutions:

    Important

    Each of these solutions routes more queries to the primary instance, which can increase its load. Evaluate the capacity of your primary instance before making changes. We recommend using hints as the preferred method to route only specific high-consistency read requests to the primary instance.