| Read/write Mode |
Specifies the read/write mode for the custom cluster endpoint. You can select Read Only or Read and Write (Automatic Read-write Splitting).
Note You can modify the read/write mode after you create the custom cluster endpoint. Changes
to the read/write mode take effect for only new connections. The existing connections
use the original read/write mode.
|
| Endpoint Name |
Specifies the name of the custom cluster endpoint. |
| Reader Nodes |
The nodes that you associate with the cluster endpoint to process read requests. You
can select the primary node and read-only nodes in the Unselected Nodes section.
Note
- If you set Read/write Mode to Read and Write (Automatic Read-write Splitting), you must select at least two nodes. Write requests are sent only to the primary
node regardless of whether the primary node is selected.
- If you set Read/write Mode to Read Only, you can select one or more nodes. You can also create a single-node endpoint to
meet your requirements. For more information, see FAQ.
|
| Automatically Associate New Nodes |
Specifies whether a new node is automatically associated with the cluster endpoint. |
| Load Balancing Policy |
Specifies the policy for scheduling read requests among multiple read-only nodes if
read/write splitting is enabled. The default value is Load-based Automatic Scheduling and cannot be changed.
|
| Consistency Level |
- If you set Read/write Mode to Read and Write (Automatic Read-write Splitting), the following consistency levels are available: Eventual Consistency, Session Consistency (Recommended), and Global Consistency. For more information, see Consistency levels.
- If you set Read/write Mode to Read Only, the default consistency level is Eventual Consistency and cannot be changed.
|
| Global Consistency Timeout |
Specifies the timeout period elapsed before the latest data is synchronized to read-only
nodes. Unit: ms. Valid values: 0 to 6000. Default value: 20.
Note This parameter is supported only if you set Consistency Level to Global Consistency.
|
| Global Consistency Timeout Policy |
Specifies the default policy to be applied if global consistency is not achieved among
the PolarDB read-only nodes within the specified period. Valid values:
- Send Requests to Primary Node (Default)
- SQL Exception: Wait replication complete timeout, please retry.
Note This parameter is supported only if you set Consistency Level to Global Consistency.
|
| Offload Reads from Primary Node |
After this feature is enabled, SQL statements are sent to only read-only nodes. This
reduces the load on the primary node and ensures the stability of the primary node.
Note You can configure this feature only after you set Read/write Mode to Read and Write (Automatic Read-write Splitting).
|
| Transaction Splitting |
Specifies whether to enable the transaction splitting feature. For more information,
see Read/write splitting.
Note You can configure this feature only after you set Read/write Mode to Read and Write (Automatic Read-write Splitting) and set Consistency Level to Session Consistency (Recommended) or Global Consistency.
|
| Connection Pool |
- Off: This is the default value.
- Session-level Connection Pool
This option is applicable to the scenarios that involve PHP short-lived connections.
Frequent PHP short-lived connections increase the load on a database. The session-level
connection pool allows you to reduce the loads that are caused by frequent PHP short-lived
connections. If a client is disconnected, the system determines whether the current
connection is idle. If the current connection is idle, PolarProxy retains the connection
in the connection pool for a short period. If the client sends a connection request
again and the idle connection is available in the connection pool, the system assigns
the idle connection to the client. The assigned connection must match the user, clientip,
and dbname variables that are specified in the client request. This reduces overheads
that are required to establish a new connection to a database. If no idle connections
are available in the connection pool, the system establishes a new connection to the
database.
Note If the session-level connection pool feature is used, the number of concurrent connections
to a database is not reduced. However, the time to establish a connection between
the client and the database is reduced. This allows you to reduce the number of main
threads that are consumed to run MySQL queries and improve service performance. However,
the connections to the database include the idle connections that are retained in
the connection pool.
- Transaction-level Connection Pool
This option is applicable to the scenarios that involve a large number of connections,
for example, more than 10,000 connections.
Transaction-level connection pools are used to reduce the number of connections to
the database and the loads that are caused by frequent short-lived connections. A
large number of connections can be established between a client and PolarProxy, but
only a small number of connections can be established between PolarProxy and a database.
When a client sends a connection request, PolarProxy selects an appropriate connection
in the connection pool to forward the request to the database. The selected connection
matches the system variables that are specified in the request. After the current
transaction is terminated, PolarProxy retains the connection in the connection pool.
Each transaction connection pool has the following limits:
- If you perform one of the following operations, a connection is locked until the connection
is closed. The locked connection is not retained in the connection pool and is unavailable
to other clients.
- Execute the PREPARE statement.
- Create a temporary table.
- Modify user variables.
- Process large packets, for example, a packet of 16 MB or a larger size.
- Execute the LOCK TABLE statement.
- Execute multiple statements.
- Call stored procedures.
- The FOUND_ROWS, ROW_COUNT, and LAST_INSERT_ID functions are not supported. These functions
can be called, but may return inaccurate results.
- If you specify the
wait_timeout parameter for a connection, the value of wait_timeout may not be applied to the client. This indicates that the connection to the client
may not time out. This is because the system assigns a connection in the connection
pool to each client request. If the time that is specified by the wait_timeout parameter is exceeded, the system closes only the connection between PolarProxy and
the database. In this case, the connection between the client and PolarProxy remains
established.
- The connection pool matches requests to connections by using the
sql_mode, character_set_server, collation_server, and time_zone variables. If the requests include other session-level system variables, you must
execute the SET statement in an explicit way to specify these additional variables
after the connections are established. Otherwise, the connection pool may reuse connections
whose system variables are changed.
- Connections may be reused. Therefore, after you execute the
SELECT CONNECTION_ID() statement, different thread IDs may be returned for the same connection.
- Connections may be reused. Therefore, after you execute the
SHOW PROCESSLIST statement, the returned IP addresses and port numbers may be different from the actual
IP addresses and port numbers of the clients.
- PolarProxy merges the results of the SHOW PROCESSLIST statements for all the nodes
and returns the merged result to clients. After the transaction-level connection pool
is enabled, the
thread ID of the connection between the client and PolarProxy is different from that between
PolarProxy and the database. As a result, the KILL statement may return an error message
even if the KILL statement is executed. You can execute the SHOW PROCESSLIST statement
to check whether the connection is closed.
Note You can configure this feature only after you set the read/write mode to Read and Write (Automatic Read-write Splitting) for the default cluster endpoint.
|
| Parallel Query |
Specifies whether to enable the parallel query feature. For more information, see
Parallel query.
Note This parameter is supported by only custom cluster endpoints in Read Only mode of PolarDB for MySQL 8.0.
|
