PolarDB:Product overview

Centralized (Enterprise Edition and Standard Edition)

• Database proxy (Proxy)

  The database proxy is a network proxy service between the database and your application. It forwards all requests from the application to the database. The proxy layer provides security authentication and advanced features such as automatic read/write splitting, load balancing, consistency levels, connection pooling, persistent connections, and overload protection.

• Database compute nodes

  • PolarDB uses a multi-node cluster architecture. Cluster Edition clusters that contain one primary node and multiple read-only nodes consist of one read/write node and multiple read-only nodes.

  • Active-active failover is used between read/write nodes and read-only nodes to provide high availability for the database service.

  • Compute nodes provide the SQL engine for the database and are available in General-purpose and Dedicated specifications.

• Shared distributed storage

  Multiple compute nodes share a single copy of data instead of each storing its own. This greatly reduces storage costs. Based on distributed block storage and a file system, storage capacity can be smoothly scaled online. This design avoids the storage capacity limits of a single database server and can handle data volumes of up to hundreds of terabytes.

Distributed

• Database nodes

  • The architecture consists of CNs and DNs. CNs are compute nodes responsible for cluster metadata management and distributed plan generation. DNs are data nodes responsible for storing actual data shards.

  • Each CN and DN uses a centralized architecture with compute-storage decoupling. It supports a database proxy and a mode with one primary node and multiple read-only nodes. It also provides high-availability failover for compute nodes within CNs and DNs. You can add read-only nodes (ROs) to scale out the read capability of a single CN or DN.

• Distributed features

  • Supports manual sharding and horizontal scaling capabilities, mainly for business scenarios with data volumes of less than 1 PB.

  • Ensures consistency for distributed transactions.

  • Supports dual-zone deployment. The primary zone hosts the working cluster, and the secondary zone hosts the hot standby cluster.

  • Provides 24/7 zero-downtime capabilities for configuration changes, upgrades, and maintenance. You can add heterogeneous CNs and DNs to the cluster.

Centralized (Standard Edition)

• Data Node (DN)

  DNs are responsible for data persistence. They provide high reliability and strong consistency based on the Paxos consensus protocol with a majority vote. The self-developed Lizard distributed transaction engine system offers more reliable high availability and an approximately 35% performance improvement compared with the native MySQL distributed engine.

• Multi-replica architecture

  To ensure strong consistency (RPO=0) among replicas, the system uses the Paxos consensus protocol with a majority vote. Each write operation must be confirmed by more than half of the nodes. Even if one node fails, the cluster can still provide services. The Paxos algorithm guarantees strong consistency among replicas, which completely resolves the issue of replica inconsistency. Replicas can be divided into the following roles:

  • Leader

    The Leader processes client requests and makes decisions. It must maintain logs to ensure data consistency and recoverability.

  • Follower

    A Follower executes instructions from the Leader. If the Leader fails or becomes inaccessible, a Follower can be elected as the new Leader.

  • Logger

    Similar to a Follower, a Logger provides only majority protocol services and does not provide data services. If the Leader fails or becomes inaccessible, a Logger participates in the election vote. It may be elected as the Leader for a short time but will not provide data services. After most Followers have caught up with the protocol logs, the Logger voluntarily steps down as Leader.

  • Learner

    A Learner can only passively receive system status information and cannot participate in voting or decision-making. This role avoids impacting the system.

Distributed (Enterprise Edition)

• Global Meta Service (GMS)

  GMS maintains globally strongly consistent system metadata, such as tables, schemas, and statistics. It also manages security information, such as accounts and permissions, and provides a global timestamp service (TSO).

• Compute Node (CN)

  The CN is the entry point of the system. It has a stateless design and includes modules such as an SQL parser, optimizer, and executor. It is responsible for distributed data routing, computation, and dynamic scheduling. It handles the coordination of the two-phase commit (2PC) protocol for distributed transactions, distributed DDL execution, and global index maintenance. It also provides enterprise-level features such as the three-role mode.

• Data Node (DN)

  The DN is responsible for data persistence for row-store data. It provides high reliability and strong consistency based on the Paxos consensus protocol with a majority vote. It also uses Multi-Version Concurrency Control (MVCC) to maintain the visibility of distributed transactions. In addition, it provides computation pushdown capabilities to meet the requirements of a distributed environment, such as pushing down Project, Filter, Join, and Aggregation computations.

• Columnar node

  This node provides persistent columnstore indexes. It builds columnstore indexes based on Object Storage Service (OSS) and consumes binary logs of distributed transactions in real time to meet real-time update needs. In conjunction with compute nodes, it provides snapshot-consistent query capabilities for columnstore data.

• Change Data Capture (CDC) node

  This node provides incremental subscription capabilities that are fully compatible with the MySQL binary log format and protocol. It also supports primary/secondary replication that is compatible with the MySQL replication protocol.