You can modify and delete cluster endpoints for PolarDB for MySQL clusters. In this topic, a default cluster endpoint is as an example to describe how to modify and delete cluster endpoints.

Modify a cluster endpoint

  1. Log on to the PolarDB console.
  2. In the upper-left corner of the console, select the region where the cluster resides.
  3. Click the ID of the cluster. Then, the Overview page appears.
  4. In the Endpoints section, find the cluster endpoint, click the Settings icon icon on the right side of the cluster endpoint, and then click Modify.
  5. In the dialog box that appears, specify the following parameters.
    Parameter Description
    Read/write Mode The read/write mode of the endpoint. Valid values: Read Only and Read and Write (Automatic Read-write Splitting).
    Note After you create a custom cluster endpoint, you can change the read/write mode of the endpoint. Changes to the read/write mode take effect for only the connections that are established after the changes are made. The connections that are established before the changes are made use the original read/write mode.
    Reader Nodes The nodes that you associate with the cluster endpoint to process read requests. In the Unselected Nodes section on the left side of the dialog box, you can select the primary node and read-only nodes
    Note
    • When the read/write mode is set to Read Only, you can create single-node endpoints. 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 production environments. We recommend that you select at least two nodes for processing read requests to improve cluster availability.
    • If the read/write mode is set to Read and Write (Automatic Read-write Splitting), you must select at least two nodes. Write requests are sent to only the primary node, regardless of whether the primary node is selected.
    Automatically Associate New Nodes Specifies whether newly added nodes are automatically associated with the cluster endpoint.
    Load Balancing Policy The policy for scheduling read requests among read-only nodes when read/write splitting is enabled. The default value is Load-based Automatic Scheduling and cannot be changed.
    Consistency Level If the read/write mode is set to Read and Write (Automatic Read-write Splitting), multiple consistency levels are available, such as Eventual Consistency, Session Consistency (Recommended), and Global Consistency. For more information, see PolarProxy features.
    Note
    • If the read/write mode is set to Read Only, the default consistency level is Eventual Consistency and cannot be changed.
    • Changes to the consistency level immediately take effect for all the connections.
    Global Consistency Timeout The amount of time to wait before global consistency is achieved among the read-only nodes. Unit: milliseconds. Valid values: 0 to 6000. Default value: 20.
    Note This parameter is available only if you set Consistency Level to Global Consistency.
    Global Consistency Timeout Policy The default policy to be applied if global consistency fails to be 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 available only if you set Consistency Level to Global Consistency.
    Offload Reads from Primary Node SQL statements are sent to read-only nodes while data consistency is ensured. This reduces the loads on the primary node and ensures the stability of the primary node.
    Note This parameter is available only if you use the Read and Write (Automatic Read-write Splitting) mode.
    Transaction Splitting Specifies whether to enable the transaction splitting feature. For more information, see PolarProxy features.
    Note This parameter is available only if you use the Read and Write (Automatic Read-write Splitting) mode.
    Connection Pool
    • Off: This is the default option.
    • 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 helps you 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 times for establishing connections between the client and the database are reduced. This helps you reduce the number of main threads that are consumed to run MySQL queries and improve service performance. However, the connections to the database include 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 tens of thousands of connections.

      The transaction-level connection pool is used to reduce the number of connections to the database and the load that is 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 created 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 completed, PolarProxy retains the connection in the connection pool for a short period.

      A 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, such as a packet of 16 MB or a larger size.
        • Execute the LOCK TABLE statement.
        • Execute multiple statements in a query.
        • Call stored procedures.
      • The FOUND_ROWS, ROW_COUNT, and LAST_INSERT_ID functions are not supported. These functions can be called, but may return invalid results.
      • If the wait_timeout parameter is set for a connection, 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 connection times out, the system closes only the connection between PolarProxy and the database, and retains the connection between the client and PolarProxy.
      • The connection pool assigns connections to requests based on 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 set these additional variables after the connections are established. Otherwise, the connection pool may reuse the connections whose system variables have been changed.
      • Connections may be reused. Therefore, the SELECT CONNECTION_ID() statement may return different thread IDs for the same connection in multiple queries.
      • 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 statement for all the nodes and returns the results 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. Therefore, the KILL statement may return an error message even if the KILL statement is executed as expected. 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.
  6. Click OK.

Delete a custom cluster endpoint

Note You can delete only custom cluster endpoints. You cannot delete default cluster endpoints.
  1. Log on to the PolarDB console.
  2. In the upper-left corner of the console, select the region where the cluster resides.
  3. Click the ID of the cluster. Then, the Overview page appears.
  4. In the Endpoints section, find the cluster endpoint, click the Settings icon icon on the right side of the cluster endpoint, and then click Delete.
  5. In the message that appears, click OK.

Related API operations

API Description
DescribeDBClusterEndpoints Queries the endpoints of a specified PolarDB cluster.
ModifyDBClusterEndpoint Modifies the attributes of a specified PolarDB cluster endpoint.
DeleteDBClusterEndpoint Deletes a custom endpoint of a specified PolarDB cluster.