Best Practices for Database Proxy

User Authentication and Connection

A user must have the remote login permission before using a database proxy to log in to databases.
To check whether the host of the account contains the CIDR block for read/write splitting, run the following SQL statement:
```
SELECT user,host FROM mysql.user;
```
If the host does not contain the CIDR block, you need to grant remote access permissions. For example, you could run the following command to grant user root the permissions to connect to the MySQL server from 192.168.0.X:
```
GRANTALL PRIVILEGES ON database.table TO 'root'@'192.168.0.%' IDENTIFIED BY 'password' WITH GRANT OPTION;
flush privileges;
```
- database.table: Names of the database and table to be accessed.
- password: Password for the user who needs to be granted access permissions.
To query the CIDR block for read/write splitting, perform the following steps:
1. On the Basic Information page of the primary instance, click the subnet name in the Connection Information area to go to the subnet console.
2. Find IPv4 CIDR Block on the Summary page.
When modifying a security group, ensure that the inbound and outbound rules allow access to the read/write splitting address. The default port for read/write splitting is 3306.
1. Log in to the management console.
2. Click in the upper left corner of the page and choose Databases > Relational Database Service.
3. On the Instances page, click in front of the DB instance and click a read replica to go to the Basic Information page.
4. In the Connection Information area, click the security group.
5. On the Inbound Rules tab, check whether access through port 3306 is allowed by default. If this rule does not exist, click Fast-Add Rule. In the displayed dialog box, select MySQL (3306) and click OK.
Database proxy does not support the identity authentication plugin caching_sha2_password of RDS for MySQL 8.0. If the error message "auth user failed" is displayed while you are attempting to access a database proxy using an RDS for MySQL 8.0 client, run the following SQL statement to check whether the identity authentication plugin is mysql_native_password:
```
select plugin from mysql.user where user="Username";
```
- If yes, add --default-auth=mysql_native_password or use an RDS for MySQL 5.* client to connect to the database proxy.
- If no, run the following SQL statements to change the identity authentication plugin to mysql_native_password:
```
ALTER USER 'Username'@'%' IDENTIFIED WITH 'mysql_native_password' BY 'Password';
FLUSH PRIVILEGES;
```

Connection Pool Configuration

To ensure that your application obtains an available connection from a connection pool, you need to configure how the connection pool will check connection availability. For example, set testOnBorrow to true for a JDBC or Druid connection pool or set connectionTestQuery to SELECT 1 for a HikariCP connection pool.

Read Requests Routed to the Primary DB Instance

If a query statement is placed in a transaction, all transaction requests will be routed to the primary DB instance. If set autocommit=0 is configured before a query statement, the query statement will be treated as a transaction and routed to the primary DB instance.
If no read replica exists, all read replicas are abnormal, or the read weights allocated to the read replicas are 0, queries will be routed to the primary DB instance. You can set read weights allocated to read replicas and the primary DB instance after read/write splitting is enabled. For details, see Configuring the Delay Threshold and Routing Policy.
If multiple statements (for example, insert ***;select ***) are executed, all subsequent requests will be routed to the primary DB instance. To restore read/write splitting, disconnect the connection from your applications and then reconnect.
Read operations with locks (for example, SELECT for UPDATE) will be routed to the primary DB instance.
When the /*FORCE_MASTER*/ hint is used, requests will be routed to the primary DB instance.