What Is Database Proxy?

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

Read/write splitting means that read and write requests are automatically forwarded through database proxy addresses. After creating a TaurusDB instance, you can create a proxy instance. With the proxy address, write requests are automatically forwarded to the primary node and read requests are forwarded to each node based on the routing policy of the proxy instance, offloading the read load from the primary node.

Proxy instances are free.

Introduction Video

Basic Concepts

Proxy Address

After buying a proxy instance, you can view the proxy address on the Database Proxy page. 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 routed to the selected nodes based on the read weights or active connections.
Read-only (TP): All read requests are routed to the selected read replicas based on the read weights or active connections. The read requests will not be 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	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	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

With transaction splitting enabled for a proxy instance, the proxy instance can route read requests prior to write operations in a transaction to read replicas, reducing the load on the primary node.

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

Connection Pool

Proxy instances provide session-level connection pools, which help reduce the database load caused by frequent establishment of short connections.

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

Routing Policy

Proxy instances support weighted 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.

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 prevent overload caused by database kernel latency, use the throttling mechanism.

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 added before a query statement, the query statement is routed to the primary node as a transaction.
If all read replicas are abnormal or the read weights allocated to the read replicas are 0, 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 will be routed to the primary node. To restore read/write splitting, disconnect your application from your instance and then connect it back again.
- 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 the HANDLER statement is executed, all subsequent requests will be routed to the primary node. To restore read/write splitting, disconnect your application from your instance and then connect it back again.
SELECT LAST_INSERT_ID()
Statements containing user-defined variables will be routed to the primary instance.