ApsaraDB RDS:Usage notes for the database proxy feature

General-purpose database proxies are provided free of charge. Dedicated database proxies, read-only ApsaraDB RDS for MySQL instances, and primary RDS instances are separately billed.

If you change the specifications of the primary RDS instance or its read-only RDS instances when the persistent connection feature is disabled for the database proxy in your database system, an instance switchover may occur. For more information about the impacts of an instance switchover, see Impacts of an instance switchover.

If you connect a newly created read-only RDS instance to a database proxy endpoint or restart an existing read-only RDS that is connected to the database proxy endpoint, a new connection to the database proxy endpoint is established. In this case, the requests that are sent over the existing and new connections to the database proxy endpoint are forwarded to the newly created or restarted read-only RDS instance.

When you disconnect a read-only RDS instance from a database proxy endpoint, errors are reported for the statements that are being executed on the read-only RDS instance. If you want to disconnect a read-only RDS instance without affecting your workloads, you must upgrade the database proxy version to 2.8.41 or later and make sure that the read and write attributes of the database proxy endpoint is Read/Write. For more information, see Upgrade the database proxy version and Configure the read and write attributes and the read weight of a database proxy endpoint.

Database proxy endpoints do not support compression protocols.

The max_prepared_stmt_count parameter must be set to the same value for the primary RDS instance that runs RDS High-availability Edition and its read-only RDS instances.

The database proxy feature uses the 1:N connection model. After your application initiates a connection request, a database proxy replicates the established connection to the primary RDS instance and all the read-only RDS instances. The maximum number of connections that are allowed for a database proxy is unlimited. The maximum number of connections varies based on the specifications of the primary RDS instance and its read-only RDS instances. If you do not enable the transaction-level connection pooling feature, the database proxy establishes a separate connection from each client to the primary RDS instance and each of the read-only RDS instances. After you enable the database proxy feature, we recommend that you specify the same maximum number of connections that are allowed for the primary RDS instance and its read-only RDS instances. If the maximum numbers of connections that are allowed for the primary RDS instance and its read-only RDS instances are different, the maximum number of connections that are allowed for the database proxy is subject to the minimum number of connections that are allowed among these RDS instances.

If your application connects to your database system by using a database proxy endpoint and transaction splitting is disabled, all requests that are encapsulated in transactions are forwarded to the primary RDS instance.

If your application connects to your database system by using a database proxy endpoint to implement read/write splitting, the read consistency of the requests that are not encapsulated in transactions cannot be ensured. If you want to ensure the read consistency of these requests, you must encapsulate these requests in transactions or add hints. For more information, see Execute hints.

If your application connects to your database system by using a database proxy endpoint, the SHOW PROCESSLIST statement returns a result set for each query. The result set consists of the query results from the primary RDS instance and read-only RDS instances.

Connection pooling is enabled by default. Therefore, the SHOW PROCESSLIST statement may return idle connections. For more information, see Set the connection pool type of an ApsaraDB RDS for MySQL instance.

If you execute multi-statements or call stored procedures, all subsequent requests over the current connection are forwarded to the primary RDS instance. To use read/write splitting again, you must close the current connection and establish a new connection.

If you use the MySQL CLI to establish a connection for which hints are added, you must add the -c option to the hints. If you do not add the option to a hint, the MySQL CLI filters the hint out. For more information about the hint syntax, see Execute hints.

If the primary RDS instance is locked, the database proxy that is enabled for the primary RDS instance is not released, but can process only read requests.

If the primary RDS instance is released, the database proxy that is enabled for the primary RDS instance is automatically released. You are no longer charged for the dedicated database proxy.

You cannot change the virtual private cloud (VPC) or vSwitch of a database proxy. If you change the VPC of the primary RDS instance, the VPC of its database proxy remains unchanged. In this case, the database proxy can still communicate with the primary RDS instance, but your client cannot use the new VPC of the primary RDS instance to connect to the database proxy endpoint.

If you use the privileged account of an RDS instance to configure a CIDR block for the host on which the RDS instance is deployed, the CIDR block can be in the 10.1.2.% format.

The IP address whitelist of the database proxy is the same as the IP address whitelist of the primary RDS instance. If the IP address whitelist of the primary RDS instance is updated, the IP address whitelist of the database proxy is also updated.

In a high-latency network environment, if you use a database proxy endpoint to subscribe to binary logs and use binary log dump threads for data transmission, the network throughput may become a performance bottleneck. This may cause a replication latency in the downstream system. We recommend that you configure database connection settings for your application or services to enable direct connections to pull binary logs.

Cross-zone migration may cause the nearest access feature to become invalid.

After the cross-zone migration, the new nearest zone can be accessed by default. The original nearest zone can no longer be accessed. If you change the zone of a proxy endpoint to a zone that is different from the default zone, the nearest access to the new zone fails. The following table describes example scenarios.

The nearest access feature is supported only for the deployment mode of four dedicated database proxy nodes in two zones. If you want to change the deployment mode or change the proxy type from dedicated to general-purpose, you must disable the nearest access feature. For more information, see Use the nearest access feature and Deployment architecture of proxy nodes.