This topic introduces the proxy terminals of ApsaraDB RDS. After you configure a proxy terminal, ApsaraDB RDS can route read and write requests to the primary and read-only RDS instances in your database system based on the read weights of these instances. This is implemented by using a proxy endpoint, which is the counterpart of the original read/write splitting endpoint.

Background information

If your database system processes a large number of read requests but a small number of write requests, a single primary RDS instance may fail to efficiently process the read requests. This may even interrupt your workloads. In this case, you can create one or more read-only RDS instances to offload the read requests from the primary RDS instance. This increases the read capability of your database system. For more information, see Overview of read-only ApsaraDB RDS for MySQL instances.

After read-only RDS instances are created, you can configure a proxy terminal. Then, a proxy endpoint can be used as the endpoint of the proxy terminal. After you add this endpoint to your application, ApsaraDB RDS routes write requests to the primary RDS instance and read requests to the read-only RDS instances based on the read weights of these instances.

If the internal or public endpoint of the primary RDS instance is added to your application, all requests are routed to the primary RDS instance. To split read and write requests, you must add the endpoints and read weights of the primary and read-only RDS instances to your application.

Benefits

  • Easier maintenance based on a unified endpoint

    If no proxy terminals are configured, you must add the endpoints of the primary and read-only RDS instances to your application to split read and write requests.

    If proxy terminals are configured, a proxy endpoint can be used to connect your application to your database system. After your application is connected to this endpoint, ApsaraDB RDS routes read and write requests to the primary and read-only RDS instances based on the read weights of these instances. This reduces maintenance costs.

    In addition, you can create read-only RDS instances to scale the read capability of your database system. In this case, you do not need to modify the configuration data on your application.

  • Higher performance and lower maintenance costs based on a native link

    You can build your own proxy layer on the cloud to split read and write requests. However, in this case, data needs to be parsed and forwarded by a number of components before it reaches your database system. This increases response latency. Proxy terminals are built in the ApsaraDB RDS ecosystem to reduce response latency, increase the processing speed, and reduces maintenance costs.

  • Ideal in various use scenarios based on configurable read weights and thresholds

    You can specify the read weights of the primary and read-only RDS instances. You can also specify a latency threshold for data replication to the read-only RDS instances.

  • Highly available based on instance-level health check

    ApsaraDB RDS actively performs health checks on the primary and read-only RDS instances. If a read-only RDS instance unexpectedly exits or its data replication latency exceeds the specified threshold, ApsaraDB RDS stops routing read requests to the instance. ApsaraDB RDS redirects the read requests destined for the faulty instance to other healthy instances. This ensures service availability in the event of faults on individual read-only RDS instances. After the faulty read-only RDS instance is recovered, ApsaraDB RDS resumes routing read requests to the instance.

    Note We recommend that you create at least two read-only RDS instances to prevent single points of failure (SPOFs).

Support for multiple proxy terminals

ApsaraDB RDS supports multiple proxy terminals. You can modify the read and write attributes of each proxy terminal based on your business requirements.

  • Read and write attributes
    • Read/Write

      The proxy terminal must be associated with at least one primary RDS instance and one read-only RDS instance. All write requests are routed to the primary RDS instance. The proxy terminal supports features such as transaction splitting and connection pool.

    • Read-only

      The proxy terminal is not associated with the primary RDS instance. However, the proxy terminal must be associated with at least one read-only RDS instance. The proxy terminal does not support features such as transaction splitting and connection pool.

      If the Read/Write Attribute parameter is set to Read-only for a proxy terminal in the ApsaraDB RDS console, the proxy terminal assigns connections to the associated read-only RDS instances based on a round-robin algorithm. This means that each database client is assigned only one connection to one read-only RDS instance. The primary RDS instance is not involved in the connection assignment by the proxy terminal. The total number of connections is the sum of connections that are established to all the read-only RDS instances.

    Note For more information about how to modify the read and write attributes of a proxy terminal, see Enable the read/write splitting feature for an ApsaraDB RDS for MySQL instance.
  • Scenario
    • Your application initiates only read requests.
    • Your application requires the splitting of read and write requests. ApsaraDB RDS allows you to create a maximum of seven proxy terminals for your database system. You can connect your application to a configured proxy terminal based on your business requirements. In addition, you can set the read and write attributes of the proxy terminal to Read/Write or Read-only.

      For example, your database system consists of one primary RDS instance and four read-only RDS instances, and you want to connect Application A and Application B to your database system. Application A initiates only read requests, and Application B initiates both read and write requests. In this case, you can use two read-only RDS instances to create Proxy Terminal A. Proxy Terminal A processes only the read requests from Application A. Then, you can use the other two read-only RDS instances to create Proxy Terminal B. Proxy Terminal B processes both the read and write requests from Application B. This way, Application A and Application B are physically isolated in your database system. This prevents mutual impacts between Application A and Application B.

Logic to route requests

  • The following requests are routed only to the primary RDS instance:
    • Requests that are used to execute INSERT, UPDATE, DELETE, and SELECT FOR UPDATE statements
    • All requests that are used to perform data definition language (DDL) operations (These DDL operations include the operations that are used to create databases or tables, delete databases or tables, and change schemas or permissions.)
    • All requests that are encapsulated in transactions
    • Requests that are used to invoke user-defined functions
    • Requests that are used to invoke stored procedures
    • Requests that are used to execute EXECUTE statements
    • Requests that are used to run multi-statement queries (For more information, see Multi Statement.)
    • Requests that involve temporary tables
    • Requests that are used to execute SELECT last_insert_id() statements
    • All requests that are used to query or reconfigure user variables
    • Requests that are used to execute SHOW PROCESSLIST statements
    • Requests that are used to execute KILL statements in SQL (These statements are not the KILL commands in Linux.)
  • The following requests are routed to the primary or read-only RDS instances:
    • Requests that are used to execute SELECT statements (These SELECT statements are not encapsulated in transactions.)
    • Requests that are used to execute COM_STMT_EXECUTE statements
  • The following requests are routed to the primary and read-only RDS instances:
    • All requests that are used to reconfigure system variables
    • Requests that are used to execute USE statements
    • Requests that are used to execute COM_STMT_PREPARE statements
    • Requests that are used to execute COM_CHANGE_USER, COM_QUIT, and COM_SET_OPTION statements