Updated on 2026-09-16 GMT+08:00

What Is Database Proxy?

Database Proxy is a network layer service that sits between TaurusDB and applications. It is used to forward all requests from applications to access TaurusDB instances.

You can enable database proxy for your TaurusDB instance to automatically forward read and write requests through a proxy address. The proxy instance forwards write requests to the primary node and read requests to read replicas based on your specified routing policy. This eases the load on the primary node.

Proxy instances are currently free of charge.

Introduction Video

Basic Concepts

Proxy Address

After buying a proxy instance, you can view the proxy address on the Database Proxy page. You can connect to this address to perform read and write operations. The proxy instance sends write requests to the primary node and read requests to read replicas through this address.

Proxy Mode

There are read/write, read-only (TP), and read-only (AP) proxy modes. The read/write attribute processing logic varies depending on the proxy mode. For details, see Table 1.

Read/Write: All write requests are routed only to the primary node, and all read requests are distributed across all the selected nodes based on their read weights or active connections.
Read-only (TP): All read requests are routed to the selected read replicas based on their read weights or active connections. Read requests are not routed to the primary node.
Read-only (AP): All read requests are routed to the selected read replicas and HTAP nodes based on the read weights.

Read-only (AP) is in the OBT phase. To use it, submit a service ticket.

**Table 1** Read/Write attribute processing logic
Proxy Mode	Routing Policy	Weight of Primary Node	Normal Case	All Read Replicas Are Faulty
Read/Write	Load balancing Nearby AZ	Assigned by the system	Primary node: readable and writable Proxy address: readable and writable	Primary node: readable and writable Proxy address: readable and writable
	Weighted	> 0	Primary node: readable and writable Proxy address: readable and writable	Primary node: readable and writable Proxy address: readable and writable
	Weighted	= 0	Primary node: not readable but writable Proxy address: readable and writable	Primary node: readable and writable Proxy address: readable and writable
Read-only (TP)	Weighted Load balancing Nearby AZ	Not configurable	The primary node does not process read-only requests. Proxy address: readable but not writable	The primary node does not process read-only requests. Proxy address: connection error
Read-only (AP)	Weighted	Not configurable	The primary node does not process read-only requests. Proxy address: readable but not writable	The primary node does not process read-only requests. Proxy address: connection error

Transaction Splitting

The database proxy service supports transaction splitting, allowing read requests issued before write operations within a transaction to be routed to read replicas. This reduces the load on the primary instance.

For more information about transaction splitting, see Enabling Transaction Splitting for a Proxy Instance.

Connection Pool

The database proxy service supports session-level connection pooling. It helps reduce high load caused by frequent short connection setups.

For more information about connection pools, see Enabling the Connection Pool for a Proxy Instance.

Routing Policy

Proxy instances support weighted, nearby AZ, and load balancing routing policies.

Weighted: Read requests are assigned to nodes based on the weights you specify.
Load balancing: Read requests are assigned to nodes with fewer active connections. In the load balancing policy, you do not need to configure the weights of nodes.
Nearby AZ: A proxy node preferentially routes read requests to the database nodes 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 delay.

For more information about routing policies, see Changing the Routing Policy of a Proxy Instance.

How Read/Write Splitting Works

You can create one or more proxy instances for your TaurusDB instance to enable read/write splitting.

If your TaurusDB instance has only one proxy instance, applications connect to the proxy instance through the proxy address. Write requests are forwarded to the primary node and read requests to the primary node or read replicas based on the routing policy you specify.

Figure 1 Read/write splitting with only one proxy instance

To isolate workloads from one another, you can create up to four proxy instances for a TaurusDB instance. Different applications can connect to different proxy instances as required. The associated read replicas of the proxy instances process read requests from different applications for workload isolation.

Figure 2 Read/write splitting with multiple proxy instances
Click to enlarge

Read/Write Splitting Advantages

Compared with manual read/write splitting in applications, the read/write splitting using proxy addresses features flexible scale-out and low maintenance costs.
Read requests are distributed to your read replicas based on weights to balance your database traffic and improve resource utilization.
A proxy instance routes read requests of an application only to its associated read replicas to isolate workloads.
By default, proxy instances provide overload protection to prevent operations with large result sets from causing out of memory (OOM) exceptions on the server. To manage performance degradation caused by slow database engine execution, the system relies on database concurrency throttling.

Request Routing Rules

Write Requests Sent Only to the Primary Node

INSERT, UPDATE, DELETE, and SELECT FOR UPDATE
All DDL operations (such as table/database creation, table/database deletion, table structure change, and permission change)
All requests in transactions (But if transaction splitting is enabled, some read requests in transactions may be sent to read replicas. For details, see Enabling Transaction Splitting for a Proxy Instance.)
User-defined functions
Stored procedures
EXECUTE statements
Multi-statement requests
Requests that use temporary tables
All changes to user variables
SELECT LAST_INSERT_ID()
KILL in SQL statements (not the kill command)
set names command in prepared statements

Read Requests Sent Only to the Primary Node

If query statements are in transactions, the transaction requests are routed to the primary node. If set autocommit=0 is executed before a query, the query is treated as a transaction and routed to the primary node.
If all read replicas are abnormal or their read weights are 0, query requests will be routed to the primary node. You can set read weights for the primary node and read replicas after read/write splitting is enabled.
When running SQL statements:
- If multi-statements (for example, insert xxx;select xxx) are executed, all subsequent requests on the current connection will be routed to the primary node. To restore read/write splitting, you must disconnect the application and re-establish the connection.
- Read operations with locks (for example, SELECT for UPDATE) will be routed to the primary node.
- When /*FORCE_MASTER*/ is used, requests will be routed to the primary node.
- If a HANDLER statement is executed, all subsequent requests on the current connection will be routed to the primary node by default. To restore read/write splitting, you must close the current connection and establish a new one.
SELECT LAST_INSERT_ID()
Statements containing user-defined variables will be routed to the primary instance.

Requests Sent Either to the Primary Node or a Read Replica

SELECT not in a transaction
The COM_STMT_EXECUTE command

Requests Always Sent to All Nodes

Changes to all system variables
The USE command

Parent Topic: Database Proxy (Read/Write Splitting)