This topic describes how the read/write splitting feature of PolarDB-X 1.0 works.
When the primary ApsaraDB RDS for MySQL instance is under a heavy load of read requests, you can use the read/write splitting feature of PolarDB-X 1.0 to distribute read traffic.
The read/write splitting feature of PolarDB-X 1.0 is transparent to the application layer. The read traffic can be distributed to the primary instance and multiple read-only instances based on the read weight that you set in the console as needed, without changing application code. All the write traffic is distributed to the primary instance.
After the read/write splitting feature is enabled, a read from the primary instance is a strong read or a real-time and strongly consistent read. However, a read from a read-only ApsaraDB RDS for MySQL instance is a weak read or a non-strongly consistent read because data on the read-only instance is asynchronously replicated from the primary instance, with a millisecond-level latency. You can use hints to assign SQL statements that require real-time and strongly consistent reads to the primary instance. For more information, see Read/write splitting.
Support for transactions
Read/write splitting is valid only for read requests (query requests) that are not in explicit transactions. An explicit transaction is one that needs to be explicitly committed or rolled back. Write requests and read requests (including read-only transactions) in explicit transactions are run in the primary instance and are not distributed to read-only instances.
The following content introduces common SQL statements for read and write requests:
- SQL statements for read requests: SELECT, SHOW, EXPLAIN, and DESCRIBE.
- SQL statements for write requests: INSERT, REPLACE, UPDATE, DELETE, and CALL.
For more information about how to set read/write splitting, see Storage management.