This topic introduces the terms that are used in PolarDB for Oracle.

Term Description
region

The geographic area of a data center where a PolarDB for Oracle cluster is deployed.
zone

A geographical area within a region. A zone has an independent power supply and network. The network latency between instances within the same zone is shorter than that between instances in different zones.
cluster

PolarDB uses a multi-node cluster architecture. A cluster has one primary node and multiple read-only nodes. A PolarDB cluster can be deployed across zones but not across regions.
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 specification. The node types include primary nodes and read-only nodes.
primary node

A primary node supports both read and write operations. Each PolarDB cluster contains only one primary node.
read-only node

You can add up to 15 read-only nodes to a PolarDB cluster.
cluster zone

A zone where the data in the cluster is distributed. The data in the cluster is automatically replicated in two zones for disaster recovery. You can migrate nodes only within these zones.
primary zone

The zone where the primary node of a PolarDB cluster is deployed.
failover

A failover is also known as a primary/secondary switchover. During a failover, a read-only node becomes the primary node. For more information, see Automatic failover and manual failover.
specification

The specification of a node in a PolarDB cluster. For example, the specification can be 8 CPU cores and 64 GB memory. For more information, see Specifications and pricing.
endpoint

An endpoint defines the access point of a PolarDB for Oracle cluster. Each cluster provides multiple endpoints. Each endpoint can be used to connect to one or more nodes. For example, requests received by the primary endpoint are forwarded to the primary node. Multiple endpoints of a cluster enable read/write splitting. The endpoints can be used to connect to the primary node and read-only nodes. An endpoint contains the attributes of database connections, such as the read/write mode, node list, load balancing, and consistency levels.
address

An address is the carrier of an endpoint on different networks. An endpoint may support a internal-facing address and an Internet-facing address. An address contains network attributes, 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 points the endpoint to the new primary node.
cluster endpoint

A cluster endpoint can be used to access all nodes in a cluster. You can enable read-only or read/write mode for a cluster endpoint. In the dialog box for configuring cluster endpoints, you can also configure cluster settings such as auto scaling, read/write splitting, load balancing, and the consistency level.
eventual consistency

By default, eventual consistency is enabled in read-only mode. PolarDB clusters deliver the optimal performance if eventual consistency is enabled. For more information, see Eventual consistency.
session consistency

Session consistency is also known as causal consistency. It is the default consistency option in read/write mode. Session consistency guarantees the read consistency at the session level to meet the requirements in most scenarios. For more information, see Session consistency.
Transaction splitting

A configuration item of cluster endpoints. To reduce the load on the primary node, enable transaction splitting. This way, the read requests in a transaction are forwarded to read-only nodes without compromising data consistency. For more information, see Features.
offload reads from the primary node

A configuration item of cluster endpoints. After this feature is enabled, SQL query statements are sent to read-only nodes without compromising data consistency. This reduces the load on the primary node to ensure the stability of the primary node. For more information, see Features.
private domain name

You can use PolarDB together with PrivateZone to reserve the domain name of your original database. This ensures that each internal-facing address of the primary endpoint and cluster endpoint of a PolarDB cluster can be associated with a private domain name. This private domain name takes effect only in the specified virtual private cloud (VPC) within the current region. For more information, see Private domain names.
snapshot backup

PolarDB allows you to back up data only by creating snapshots. For more information, see Backup and recovery.
level-1 backup

A backup file that is locally stored in the cluster is a level-1 backup. Level-1 backups are stored in the distributed storage system that is associated with a cluster. These backups allow you to back up and restore data in a quick manner. However, level-1 backups have high costs. For more information, see Backup and recovery.
level-2 backup

Level-2 backups are backup files that are stored in on-premises storage media. All data in level-2 backups is archived from level-1 backups and can be permanently stored. Level-2 backup have low costs. However, a long time is required to restore data from level-2 backups. For more information, see Backup and recovery.
log backup

A log backup stores the redo logs of a database for point-in-time recovery (PITR). Log backups help avoid data loss caused by misoperations. Log backups must be retained for at least seven days. Log backups are stored in on-premises storage and are cost-effective. For more information, see Backup and recovery.
storage plan

PolarDB provides storage plans to reduce the storage costs of clusters. The storage capacity of a PolarDB cluster is automatically scaled based on the amount of the data in the cluster. You do not need to manually specify the storage capacity. You are charged only for the used storage. If you need to store a large amount of data, we recommend that you purchase PolarDB storage plans to reduce the cost. For more information, see Purchase a storage plan.
parallel execution PolarDB for Oracle provides the cross-node parallel execution feature. After you enable this feature, an SQL statement can be executed on multiple nodes in parallel. This way, you can make full use of the hardware resources of all the compute nodes, such as CPUs, memory, and network resources. This improves the performance of analytical queries. For more information, see Cross-node parallel execution.