Product overview

Centralized (Enterprise Edition and Standard Edition)

• Database proxy (Proxy)

  A network proxy between the database and your application that forwards all requests. Provides security authentication, 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 provides one read/write node and multiple read-only nodes.

  • Active-active failover between read/write and read-only nodes ensures high availability.

  • Compute nodes host the SQL engine and come in General-purpose and Dedicated specifications.

• Shared distributed storage

  All compute nodes share a single data copy, reducing storage costs. Built on distributed block storage, capacity scales online up to hundreds of terabytes without single-server limits.

Distributed

• Database nodes

  • CNs handle cluster metadata management and distributed plan generation. DNs store actual data shards.

  • Each CN and DN uses a centralized, compute-storage decoupled architecture with database proxy and one-primary-multiple-read-only mode. High-availability failover is built in. Add read-only nodes (ROs) to scale out read capability.

• Distributed features

  • Manual sharding and horizontal scaling for data volumes under 1 PB.

  • Ensures consistency for distributed transactions.

  • Dual-zone deployment: primary zone for the working cluster, secondary zone for hot standby.

  • 24/7 zero-downtime configuration changes, upgrades, and maintenance. Supports heterogeneous CN and DN additions.

Centralized (Standard Edition)

• Data Node (DN)

  DNs handle data persistence with high reliability and strong consistency via the Paxos majority-vote protocol. The self-developed Lizard distributed transaction engine system delivers ~35% better performance than the native MySQL distributed engine.

• Multi-replica architecture

  The system uses Paxos majority-vote consensus to ensure strong consistency (RPO=0) among replicas. Each write must be confirmed by more than half the nodes, so the cluster tolerates single-node failures. Replica roles:

  • Leader

    Processes client requests and makes decisions. Maintains logs for data consistency and recoverability.

  • Follower

    Executes instructions from the Leader. Can be elected as the new Leader if the current Leader fails.

  • Logger

    Participates in majority protocol voting without providing data services. May serve as interim Leader after a failure until Followers catch up with protocol logs, then steps down.

  • Learner

    Passively receives system status without participating in voting or decisions.

Distributed (Enterprise Edition)

• Global Meta Service (GMS)

  Maintains globally consistent metadata (tables, schemas, statistics), manages security (accounts, permissions), and provides a global timestamp service (TSO).

• Compute Node (CN)

  The stateless entry point of the system, with SQL parser, optimizer, and executor. Handles distributed data routing, 2PC transaction coordination, distributed DDL, and global index maintenance. Supports enterprise features like three-role mode.

• Data Node (DN)

  Persists row-store data with high reliability and strong consistency via Paxos majority-vote. Uses MVCC for distributed transaction visibility. Supports computation pushdown (Project, Filter, Join, Aggregation) for distributed workloads.

• Columnar node

  Provides persistent columnstore indexes built on OSS. Consumes distributed transaction binary logs in real time for live updates. Works with compute nodes to deliver snapshot-consistent columnstore queries.

• Change Data Capture (CDC) node

  Provides incremental subscriptions fully compatible with MySQL binlog format and protocol. Supports MySQL-compatible primary/secondary replication.