Changing the Routing Policy of a Proxy Instance

Read requests are assigned to nodes based on the weights you specify.

As shown in the figure, when the proxy instance uses weighted routing and selects the primary node and read replicas R1 and R2 with a read weight ratio of 0:1:2, application A's write requests are automatically forwarded to the primary node while read requests are routed to read replicas R1 and R2 at a 1:2 ratio.

Figure 1 Weighted routing

Read requests are distributed based on the number of active connections. Read requests are routed to nodes with fewer active connections. No weight configuration is required for this policy.

Depending on the source of load data, the load balancing routing policy has two modes:

• Load balancing (database nodes): Active connection counts are obtained from database nodes and used as the basis for request distribution.
  • Application scenarios
    • Multiple proxy instances connected to the same group of database nodes: The number of active connections is a global metric, so all proxy instances see the same load status. This prevents multiple proxy instances from routing requests to the same node simultaneously.
    • The overall load on backend database nodes needs to be monitored.
    • Real-time routing decisions are not a priority.
  • How it works

    The database proxy instance periodically queries the number of active connections on each database node. When a read request arrives, the proxy instance routes it to the node with the fewest active connections. If multiple nodes have the same number of active connections, one is selected at random.

    As shown in the following figure, the proxy instance uses the load balancing (database nodes) routing mode, with the primary node and read replicas R1 and R2 selected. The proxy instance determines which node to forward read requests to based on the number of active connections on each node.

    When read replica R2 has a high number of active connections and is under heavy load, the proxy instance forwards most read requests to read replica R1 and the primary node, which have lower loads, to reduce pressure on R2.

    Figure 2 Load balancing (database nodes)
    
• Load balancing (proxy nodes): The proxy instance locally tracks the number of active connections and distributes requests based on the connection counts updated in real time.
  • Application scenarios
    • Real-time routing decisions are critical: Connection counts are updated in real time without delay.
    • Nodes overloaded by slow SQL queries need to be accurately identified: Connections remain counted as active while they are occupied by slow SQL query. This allows the proxy instance to accurately identify heavily loaded nodes and avoid routing requests to them.
    • Backend resource overhead needs to be reduced: The proxy instance does not need to periodically query database node status, reducing backend connection resource consumption.
  • How it works

    The proxy instance locally tracks the number of active connections from itself to each database node in real time. When a read request arrives at the current proxy node, the proxy node routes it to the database node with the fewest active connections.

    Unlike the load balancing (database nodes) routing policy, the load balancing (proxy nodes) policy does not require queries to database nodes. All load data is maintained locally by each proxy instance in real time.

    As shown in the following figure, each proxy node independently tracks the number of active connections from itself to each database node. For example, R1 = 3 indicates that the proxy node has three active connections to read replica R1. Each proxy node routes read requests to the database node with the fewest active connections. Because the requests received by each proxy node differ in source and timing, the connection counts on different proxy nodes may vary at the same time. However, each proxy node independently routes requests to the node with the fewest active connections. Overall, the number of active connections across database nodes tends to become balanced. In the following figure, both R1 and R2 have six active connections.

    Figure 3 Load balancing (proxy nodes)
    

A proxy node preferentially routes read requests to the database nodes located in the same AZ as the proxy node. In this policy, you are advised to deploy the proxy instance and the TaurusDB nodes in the same AZ to reduce the distribution latency.

As shown in the figure, the proxy instance contains two nodes located in different AZs (AZ 1 and AZ 2). Write requests are routed to the primary node (M) and read requests are routed to the nearest nodes based on the AZ of the application (M and R1 in AZ 1; R2 and R3 in AZ 2) to reduce network latency and improve performance. When all proxy nodes are in AZs different from all TaurusDB instance nodes, the routing policy switches to load-balancing mode.

Figure 4 Nearby AZ routing