You can create custom cluster endpoints for PolarDB for MySQL clusters. When you create custom cluster endpoints, you can set the read/write mode, consistency level, and associated read-only nodes to meet your business requirements and improve service flexibility. This topic describes how to create a custom cluster endpoint for a PolarDB for MySQL cluster.
- The product edition must be PolarDB for MySQL Cluster Edition. Both Single Node and Archive Database do not support this feature. For more information about the three editions, see Product editions.
- Parallel queries and parallelism are supported only when you configure a custom cluster endpoint for a PolarDB for MySQL 8.0 cluster.
- Log on to the PolarDB console.
- In the upper-left corner of the console, select the region where the cluster is deployed.
- Find the cluster and click the ID of the cluster. The Overview page appears.
- In the Endpoints section, click Create Custom Cluster Endpoint.
- In the Create Custom Cluster Endpoint dialog box, set the following parameters.
Parameter Description 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:
Note This parameter is supported only if you set Consistency Level to Global Consistency.
- Send Requests to Primary Node (Default)
- SQL Exception: Wait replication complete timeout, please retry.
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
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.
- 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_timeoutparameter for a connection, the value of
wait_timeoutmay 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_timeoutparameter 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
time_zonevariables. 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 IDsmay be returned for the same connection.
- Connections may be reused. Therefore, after you execute the
SHOW PROCESSLISTstatement, 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 IDof 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.
- 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.
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.
- Click OK.
- Q: How do I create a single-node endpoint?
A: You can create one or more single-node endpoints only if Read/write Mode is set to Read Only and the cluster has at least three nodes. When you create single-node endpoints, you can specify only read-only nodes as reader nodes. The reader nodes are the backend nodes that process read requests. For more information, see Procedure.Warning However, if you create a single-node endpoint for a read-only node and the read-only node becomes faulty, the single-node endpoint may be unavailable for up to one hour. We recommend that you do not create single-node endpoints in your production environment.
- Q: What is the maximum number of single-node endpoints that I can create in a cluster?
A: The maximum number of the single-node endpoints that are allowed in a cluster varies based on the number of nodes in the cluster. If your cluster has three nodes, you can create a single-node endpoint for only one of the read-only nodes. If your cluster has four nodes, you can create two single-node endpoints for two of the read-only nodes, one for each read-only node. Similar rules apply if your cluster has five or more nodes.
- Q: If a single-node endpoint is created for a read-only node, can the read-only node
function as the new primary node after a failover?
A: The read-only node that is configured with a single-node endpoint cannot be automatically used as the new primary node after a failover. However, you can manually specify the read-only node as the new primary node. For more information, see Switch over services between primary and read-only nodes.
- Q: What is the maximum number of cluster endpoints for a cluster?
A: A cluster can have a maximum of four cluster endpoints. One is the default cluster endpoint and the other three are custom cluster endpoints.
- Q: Can I modify a cluster endpoint?
A: Yes, you can modify the default cluster endpoint and custom cluster endpoints. For more information, see Modify a cluster endpoint.
- Q: Can I delete a cluster endpoint?
A: Yes, you can delete a cluster endpoint. However, you can delete only custom cluster endpoints, and you cannot delete the default cluster endpoint. For more information, see Delete a custom cluster endpoint.
Related API operations
|CreateDBClusterEndpoint||Creates a custom cluster endpoint for a PolarDB cluster.|
|DescribeDBClusterEndpoints||Queries the endpoints of a specified PolarDB cluster.|