Help Center/ Relational Database Service/ User Guide (Ankara Region)/ Working with RDS for MySQL/ Database Proxy (Read/Write Splitting)/ Introducing Read/Write Splitting
Updated on 2024-04-11 GMT+08:00
View PDF
Share

Introducing Read/Write Splitting

Read/write splitting enables read and write requests to be automatically routed through a read/write splitting address. You can enable read/write splitting after read replicas are created. Write requests are automatically routed to the primary DB instance and read requests are routed to read replicas by user-defined weights.

To use read/write splitting, connect to DB instances through a private network because read/write splitting addresses are private IP addresses.

Constraints

When read/write splitting is enabled, the system automatically deletes the existing account rdsProxy and creates a new rdsProxy account. When read/write splitting is disabled, the system automatically deletes the existing account rdsProxy. To prevent the system from deleting your created rdsProxy account, you are advised not to create it.

  • RDS for MySQL 5.6 and 5.7 support read/write splitting, but RDS for MySQL 8.0 does not.
  • The RDS for MySQL 8.0 client does not support connections using the read/write splitting address.
  • If you delete a primary DB instance after read/write splitting is enabled, the read replicas are also deleted and the read/write splitting function is disabled.
  • After read/write splitting is enabled, the database port, security group, and floating IP address of the primary DB instance and read replica cannot be changed.
  • Read/write splitting does not support SSL encryption.
  • Read/write splitting does not support the compression protocol.
  • Read/write splitting does not support the READ UNCOMMITTED transaction isolation level.
  • If multi-statements are executed, all subsequent requests will be routed to the primary DB instance. To restore the read/write splitting function, disconnect the connection from your applications and establish a connection again.
  • When read and write requests are split through the read/write splitting address, all transaction requests are routed to the primary DB instance while the non-transaction read consistency is not ensured. To ensure read consistency, encapsulate requests into transactions.
  • When the read/write splitting address is used, the LAST_INSERT_ID() function can be used only in transactions.
  • When the read/write splitting address is used, the execution results of the show processlist command are inconsistent.
  • When the read/write splitting address is used, the show errors and show warnings commands are not supported.
  • When the read/write splitting address is used, user-defined variables, such as the SET @variable statements, are not supported.
  • When the read/write splitting address is used, if stored procedures and functions depend on user variables (@variable), the execution result may be incorrect.