You can modify and delete cluster endpoints for Apsara PolarDB clusters. This topic uses a PolarDB MySQL cluster as an example to describe how to modify and delete cluster endpoints.

Modify a cluster endpoint

  1. Log on to the Apsara PolarDB console.
  2. In the upper-left corner of the console, select the region where the target cluster resides.
  3. Click the ID of the cluster. The Overview page appears.
  4. In the Endpoints section, find the target cluster endpoint, click the Settings icon icon on the right side of the cluster endpoint, and then click Modify. This topic uses the default cluster endpoint as an example.
  5. In the dialog box that pops up, set the following parameters.
    Parameter Description
    Read/write Mode The read/write mode. The settings determine whether you can send read requests or read/write requests to the endpoint. Valid values: Read Only and 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 only for 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. You can select the primary node and read-only nodes in the Unselected Nodes section on the left side of the dialog box.
    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 1 hour. We recommend that you do not create single-node endpoints in the production environment. 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 only to the primary node regardless of whether the primary node is selected.
    Automatically Associate New Nodes Specifies whether a new node is automatically associated with the cluster endpoint.
    Load Balancing Policy 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.
    Offload Reads from Primary Node SQL query statements are sent only to read-only nodes based on a precondition that ensures data consistency. This reduces the loads on the primary node and ensures the stability of the primary node.
    Note You can configure this feature only after you set the read/write mode to Read and Write (Automatic Read-write Splitting).
    Consistency Level If the read/write mode is set to Read and Write (Automatic Read-write Splitting), the consistency level options are Eventual Consistency, Session Consistency (Recommended), and Global Consistency. For more information, see Data consistency levels.
    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 take effect immediately for all connections.
    Transaction Splitting Specifies whether to enable the transaction splitting feature. For more information, see Configure transaction splitting.
    Note You can configure this feature only after you set the read/write mode to Read and Write (Automatic Read-write Splitting).
    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 loads 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 from a connection, the system determines whether the connection is idle. If the 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 10,000 connections.

      The transaction-level connection pool is 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 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 terminated, PolarProxy retains the connection in the connection pool for a short period.

      Limits:

      • If you perform one of the following operations, a connection is locked until the connection is terminated. 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 in a query.
        • Call stored procedures.
      • You cannot call the FOUND_ROWS, ROW_COUNT, and LAST_INSERT_ID functions. These functions may return invalid results even if you call these functions successfully.
      • 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 disconnects only the connection between PolarProxy and the database, but retains the connection between the client and PolarProxy.
      • 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 set these additional variables after the connections are established. Otherwise, the connection pool may reuse 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 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. 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 disconnected.
    Note You can configure this feature only after the read/write mode of the default cluster endpoint is set to Read and Write (Automatic Read-write Splitting).
  6. Click OK.

Delete a custom cluster endpoint

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

Related operations

API Description
CreateDBClusterEndpoint Creates a custom cluster endpoint for an Apsara PolarDB cluster.
DescribeDBClusterEndpoints Queries the cluster endpoints for an Apsara PolarDB cluster.
ModifyDBClusterEndpoint Modifies a cluster endpoint for an Apsara PolarDB cluster.
DeleteDBClusterEndpoint Deletes a custom cluster endpoint for an Apsara PolarDB cluster.