Cluster endpoints and primary endpoints - PolarDB for MySQL

The endpoints of a PolarDB cluster are classified into two types: cluster endpoint and primary endpoint. To connect to a PolarDB cluster, you can use either the primary endpoint or a cluster endpoint of the PolarDB cluster. This topic describes the use scenarios of and differences between cluster endpoints and primary endpoints.

Comparison between cluster endpoints and primary endpoints


Endpoint type	Description	Scenario	Supported network type
Cluster endpoint (recommended)	The cluster endpoint is implemented by using PolarProxy. Cluster endpoints have the following features: PolarDB PolarProxy provides the read/write splitting feature. This feature enables PolarDB clusters to distribute read and write requests from applications by using cluster endpoints. The built-in proxy of a PolarDB cluster forwards write requests to the primary node, and forwards read requests to the primary node or read-only nodes based on the loads on nodes. A PolarDB cluster provides one cluster endpoint by default and allows you to create up to six cluster endpoints based on your business requirements. When you create a cluster endpoint, you can configure the read/write mode for the cluster endpoint and specify the nodes to which the cluster endpoint can connect. To use the features of PolarProxy, you must use a cluster endpoint to connect to the PolarDB cluster. For more information, see PolarProxy. Note PolarDB allows you to create single-node cluster endpoints. If the node that is associated with a single-node cluster endpoint is faulty, the single-node cluster endpoint may remain unavailable for up to 1 hour. We recommend that you do not use single-node cluster endpoints in your production environment.	Scenarios that require data isolation. You can use different cluster endpoints to connect your services to a PolarDB cluster based on your business requirements. Cluster endpoints can be configured in one of two read/write modes: read and write (automatic read/write splitting) or read-only. As a result, cluster endpoints can also be used for read-only services. For example, assume that you have purchased a PolarDB cluster that contains one primary node and four read-only nodes. You want to connect Service A and Service B to this cluster. Service A is a read-only service and Service B is a read/write service. You can create cluster endpoint A that runs in read-only mode for Service A and associate cluster endpoint A with read-only node 1 and read-only node 2. Then, create cluster endpoint B that runs in read and write (automatic read/write splitting) mode for Service B and associate cluster endpoint B with read-only node 3 and read-only node 4. This way, the data of Service A is physically isolated from that of Service B.	Internal network Internet
Primary endpoint	Each PolarDB cluster supports only a single primary endpoint. The primary endpoint has the following features: The primary endpoint allows you to connect to the primary node of the cluster. The primary endpoint can be used for read and write operations. When the primary node is faulty, the primary endpoint is switched to a new primary node.	Scenarios that do not require read/write splitting.	Internal network Internet

Private endpoints and public endpoints


Network type	Description	Scenario
Internal network	A PolarDB cluster achieves optimal performance when the cluster is connected by using an internal endpoint. When you create a cluster, a default private endpoint is created. This endpoint can be modified but not deleted. For more information, see Modify an endpoint.	Examples: If your Elastic Compute Service (ECS) instance is deployed in the same virtual private cloud (VPC) as the cluster, your ECS instance can connect to the cluster by using a private endpoint. You can use Data Management (DMS) to connect to the cluster over an internal network.
Internet	You can apply for or delete a public endpoint. For more information, see Apply for a cluster endpoint or a primary endpoint. A PolarDB cluster cannot achieve optimal performance when it is connected by using a public endpoint.	For example, you can connect to your cluster by using a public endpoint to perform O&M operations.

Read/Write modes for cluster endpoints

You can set the read/write mode to Read and Write (Automatic Read-write Splitting) or Read Only for a cluster endpoint. The following table describes the differences between cluster endpoints that use different read/write modes.

Note For information about how to configure the read/write mode for a cluster endpoint, see Configure PolarProxy.


Item	Read and Write (Automatic Read-write Splitting)	Read Only
Associated nodes	Nodes can be associated with the cluster endpoint in one of the following three configurations: Only the primary node One or more read-only nodes The primary node and one or more read-only nodes Note In read and write mode: All write requests are sent only to the primary node, regardless of whether the primary node has been added to the list of service nodes. For read requests, you can configure Primary Node Accepts Read Requests to specify whether the primary node processes read requests.	Only the following configurations are supported: One or more read-only nodes Note In read-only mode: Read requests are forwarded to read-only nodes in load balancing mode. All read requests are not forwarded to the primary node. Even if the primary node is added to the list of service nodes, read requests are still not forwarded to it. You cannot create a read-only cluster endpoint that contains only one primary node.
Load Balancing Policy	Active Request-based Load Balancing is supported. For more information, see Load balancing policies.	Load Balance Based on Connections and Active Request-based Load Balancing are supported. For more information, see Load balancing policies.
Primary Node Accepts Read Requests	Supported. For more information, see Read/Write splitting.	This feature is used to reduce the loads on the primary node. However, the primary node that is associated with a Read Only cluster endpoint does not process read or write requests. Therefore, this feature is redundant.
Transaction Splitting	Supported. For more information, see Transaction splitting. Note This configuration is supported only if Consistency Level is Session Consistency (Medium) or Global Consistency (Strong).	This feature is used to reduce the loads on the primary node. However, the primary node that is associated with a Read Only cluster endpoint does not process read or write requests. Therefore, this feature is redundant.
Consistency Level	Eventual Consistency (Weak), Session Consistency (Medium), and Global Consistency (Strong) are supported. For more information, see Consistency levels.	This parameter is set to Eventual Consistency (Weak). The cluster endpoint in this mode does not process write requests.
Connection Pool	Session-level and Transaction-level connection pools are supported. For more information, see Connection pools. Note This connection pool feature is provided by PolarProxy of PolarDB. This feature does not affect the connection pool feature in your clients. If the client provides a connection pool, you can set Connection Pool to Off in the PolarDB console to disable the connection pool feature of PolarProxy. After you set Connection Pool to Off, PolarProxy sends a request from the client to all nodes that are associated with the cluster endpoint. These nodes include the primary node and the read-only nodes. The total number of available connections is limited by the maximum number of connections that can be established to the primary node.	Not supported. Note PolarDB evenly distributes requests among all read-only nodes that are associated with the Read Only cluster endpoint. The primary node does not process requests. PolarProxy sends a request from a client to only a single node. The total number of available connections is equal to the total number of connections to all read-only nodes.
Security Protection	Supported. For more information, see Overload protection.	Not supported.