This topic describes how the read/write splitting feature works in PolarDB-X 1.0.
If the MySQL primary instance of a PolarDB-X 1.0 storage resource is under high read pressure from many read requests, you can use the read/write splitting feature to distribute read traffic. This reduces the read pressure on the storage layer.
The read/write splitting feature in PolarDB-X 1.0 is transparent to applications. No application code changes are needed. You can adjust the read weights in the console to distribute read traffic between the MySQL primary instance and multiple read-only instances based on custom weight ratios. Write traffic is not distributed and is always directed to the primary instance.
After you enable read/write splitting, reads from the MySQL primary instance are strong reads. Strong reads are real-time and provide strong consistency. Data on read-only instances is replicated asynchronously from the primary instance, which introduces a delay of several milliseconds. As a result, reads from read-only instances are weak reads and do not provide strong consistency. You can use hints to send read-only SQL queries that require real-time data and strong consistency to the primary instance. For more information, see Read/write splitting.
Support for transactions in read/write splitting
Read/write splitting affects only read requests (queries) that are outside of explicit transactions. An explicit transaction requires an explicit commit or rollback. Write requests and read requests within explicit transactions, including read-only transactions, always run on the primary instance and are not distributed to read-only instances.
Common SQL statements for read and write requests include the following:
- Read requests: SELECT, SHOW, EXPLAIN, DESCRIBE.
- Write requests: INSERT, REPLACE, UPDATE, DELETE, CALL.
For more information about how to set up read/write splitting, see Storage management.