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 or the primary DB instance by user-defined weights.
- 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.
- If the read/write splitting connection address is used, you need to disable Query Cache on RDS. For details, visit https://bugs.mysql.com/bug.php?id=83346.
- RDS for MySQL 5.6 and 5.7 support read/write splitting, but MySQL 8.0 does not.
- The MySQL 8.0 client does not support connections using the read/write splitting address.
- Read/write splitting is available only for primary/standby DB instances with 4 vCPUs or more (except for the DB instances created in a DeC).
- At least one read replica is required for enabling read/write splitting.
- 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.
- If multi-statements are executed, all subsequent requests will be routed to the primary DB instance. To restore the read/write splitting function, you need to disconnect the connection between applications and the read/write splitting address 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 can be used only in transactions.
- 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.