This topic describes the terms that are commonly used in PolarDB.

Term Description
Region The geographic location of a data center where a PolarDB cluster is deployed.
Zone A physical location with independent power grids and networks within a region. The network latency between instances within the same zone is shorter than that between instances in different zones.
Cluster PolarDB uses a distributed cluster-based architecture. Each cluster consists of one primary node (read/write node) and multiple read-only nodes. A PolarDB cluster can be deployed across zones but not across regions.
Global Database Network (GDN) GDN is a network that consists of multiple PolarDB clusters that are distributed across regions around the world. All clusters in the network synchronize with each other to reach data consistency. For more information, see Create and release a GDN.
Primary Cluster In each GDN, only one cluster is granted the read and write permissions. This read/write cluster is also known as the primary cluster.
Secondary Cluster In each GDN, these clusters synchronize data from the primary cluster.
Node A PolarDB cluster consists of multiple physical nodes. Each cluster consists of two types of nodes. Both node types are equivalent and have the same specifications. These two types of nodes are known as primary nodes and read-only nodes.
Primary Node Each PolarDB cluster contains one primary node, which is a read/write node.
Read-only Node You can add up to 15 read-only nodes to a PolarDB cluster.
Cluster Zone The zone where cluster data is distributed. Cluster data is automatically replicated in two zones for disaster recovery. Node migration can only be performed within these zones.
Primary Zone The zone where the PolarDB primary node is deployed.
Failover A read-only node can be specified as the new primary node. For more information, see Switch over services between primary and read-only nodes.
Class The specifications of a PolarDB cluster, which specify the specifications of each node, such as 8-core, 64 GB. For more information, see Billable items.
Endpoint An endpoint defines the access point of a PolarDB cluster. Each cluster provides multiple endpoints (access points). Each endpoint can connect to one or more nodes. For example, requests received from a primary endpoint are sent to only the primary node. Cluster endpoints provide the read/write splitting feature. Each cluster endpoint can connect one primary node and multiple read-only nodes. An endpoint contains the attributes of database connections, such as read/write mode, node list, load balancing, and consistency levels.
Address An address serves as the carrier of an endpoint on different networks. An endpoint may support a VPC-facing address and an Internet-facing address. An address contains network properties, such as the domain name, IP address, VPC, and vSwitch.
Primary Endpoint The endpoint of the primary node. If a failover occurs, the system automatically connects the primary endpoint to the new primary node.
Cluster Endpoint A cluster endpoint is a read/write address. Multiple nodes within a cluster use the cluster endpoint to provide services. You can set the cluster endpoint to read-only or read/write mode. Cluster endpoints support features such as auto-scaling, read/write splitting, load balancing, and consistency levels.
Eventual Consistency By default, eventual consistency is enabled in read-only mode. PolarDB clusters can deliver the best performance based on eventual consistency. For more information, see Eventual consistency.
Session Consistency Session consistency is also known as causal consistency, which is the default option in read/write mode. It ensures the consistency of read requests across sessions to meet the requirements in most scenarios. For more information, see Session consistency.
Global Consistency Global consistency is also known as strong consistency, cross-session consistency, and highest-level consistency. It ensures the session consistency, but increases the workload on the primary node. When the replication latency between the primary node and read-only nodes is high, we recommend that you do not use global consistency. For more information, see Global consistency.
Distributed Transaction A configuration item of cluster endpoints. The transaction splitting feature splits read requests from transactions and forwards these requests to read-only nodes without compromising session consistency. This can reduce the workload on the primary node. For more information, see Features.
Offload Reads from Primary Node A configuration item of cluster endpoints. SQL statements are sent to read-only nodes while data consistency is achieved. This reduces the loads on the primary node and ensures the stability of the primary node. For more information, see Features.
Private Address You can use PolarDB with PrivateZone to reserve the connection address (domain name) of your original database. This ensures that each private address of the primary endpoint and cluster endpoint of PolarDB can be associated with a private domain name. This private address takes effect only in the specified VPC within the current region. For more information, see Private domain names.
Snapshot Backup PolarDB only allows you to back up data only by creating snapshots. For more information, see Overview.
Level-1 Backup A backup file that is locally stored in the cluster is a level-1 backup. Level-1 backups are stored on distributed storage clusters. These backups allow you to quickly back up and restore the cluster, but cause high costs. For more information, see Overview.
Level-2 Backup Level-2 backups are backup files stored in local storage media. All data in level-2 backups is archived from level-1 backups and can be permanently stored. Level-2 backups require a longer time to restore the cluster but are cost-effective. For more information, see Overview.
Log Backup A log backup stores the Redo logs of a database for point-in-time recovery (PITR). Log backups can avoid data loss due to user errors and ensure data security. Log backups must be kept at least 7 days. Log backups are stored in local storage and are cost-effective. For more information, see Overview.
Storage Plan The resource plan that is provided by PolarDB to reduce the storage costs of clusters. The storage capacity of PolarDB is automatically scaled in or out based on the amount of the stored data. You do not need to manually specify the storage capacity. You are charged for only the used storage. If you want to store a large volume of data, we recommend that you purchase PolarDB storage plans. This reduces the storage costs. For more information, see Purchase a storage plan.
Cluster Edition Cluster Edition is the recommended edition and uses an architecture where computing is decoupled from storage. At the computing layer, the number of database nodes can be increased from 2 to 16. For more information, see Cluster Edition.
Single Node As the starter of ApsaraDB PolarDB MySQL-compatible edition editions, Single Node uses the burstable performance specification and shares resources in a computing resource pool to improve resource usage. The Single Node architecture also reduces resource costs because no proxy is required. For more information, see Single node.
Archive Database Archive Database provides a high compression ratio and uses X-Engine as the default storage engine. PolarDB Archive Database provides a large storage capacity and allows you to store archived data at a low cost. For more information, see Archive Database.