This topic provides a list of commonly asked questions (FAQ) about ApsaraDB for PolarDB.

What is ApsaraDB for PolarDB?

ApsaraDB for PolarDB is a cloud-native relational database service that is compatible with the MySQL, PostgreSQL, and Oracle engines. ApsaraDB for PolarDB has been tried and tested during the Double 11 Global Shopping Festival. ApsaraDB for PolarDB provides performance that is on par with commercial database engines while being elastic and cost-effective as open-source database engines.

ApsaraDB for PolarDB is designed to handle large amounts of concurrent queries. Each ApsaraDB for PolarDB cluster supports up to 100 TB of storage space and can handle up to one million queries per second (QPS). An ApsaraDB for PolarDB cluster can also be scaled out to a maximum of 16 nodes, and provide up to 6 times of performance improvement over traditional MySQL clusters at a 30% to 50% cost reduction. ApsaraDB for PolarDB has high performance and high security. ApsaraDB for PolarDB can scale clusters within a few minutes, recover from failures within a few seconds, and guarantee data consistency.

In 2018, ApsaraDB for PolarDB clusters replaced the traditional Oracle databases in the Alibaba Cloud ecosystem and provided substantial support for handling 98% of the transactions during the Double 11 Global Shopping Festival. On November 11, 2018, ApsaraDB for PolarDB succeeded in meeting the challenges of a transaction load that increased by 122 times in just a few seconds. From that time forward, ApsaraDB for PolarDB has been a core product of Alibaba Group.

Why should I choose ApsaraDB for PolarDB?

The rapid development of IT and Internet technologies requires frequent interaction between enterprises and their customers. The data volume generated from these interactions grows at an exponential rate. Consequently, you may experience the following challenges:

  • Storage limitations

    Due to the limitations of traditional MySQL databases, such as the use of physical disks and traditional data backup technology, a MySQL database cannot store data greater than 3 TB. It would be cost-prohibitive to maintain databases whose data volume exceeds 3 TB. To resolve this problem, you have to scale out databases, migrate data, and shard databases to keep pace with the fast growth of data. This not only increases development costs, but also may cause service interruption.

  • Scalability limitations

    In a traditional database cluster, the read/write and read-only nodes each have their own replicas. If you want to add a read-only node, you have to replicate all of the existing data. Due to network caps, the entire replication process can be time-consuming.

  • Data consistency and availability limitations

    In a traditional database cluster, the read/write and read-only nodes use incremental synchronization to replicate binary logs between each other. All SQL statements that are executed on the read/write node must also be executed on each read-only node. This causes a latency of data replication between the read/write and read-only nodes. Therefore, it takes a period of time for data on both nodes to reach consistency. If an application retrieves data from a read-only node, the integrity of data cannot be guaranteed. Additionally, this latency may adversely affect node switchover and cluster availability.

ApsaraDB for PolarDB leverages the technology that has been tested by the Double 11 Global Shopping Festival for over 10 years. The advancement of technology allows ApsaraDB for PolarDB to adopt the elasticity of open-source database engines and the high performance of commercial database engines with lower costs.

  • Volumetric data storage

    Each ApsaraDB for PolarDB cluster supports a maximum of 100 TB of storage space and can be scaled out to a maximum of 16 nodes. Each node can have up to 88 vCPUs. The serverless, distributed storage architecture allows you to scale clusters to fit the amount of data to be stored. Fees are charged based on the actual storage usage.

  • Extremely fast scaling against workload spikes

    Compute and storage are decoupled on the ApsaraDB for PolarDB architecture. Both compute and storage nodes are optimized to improve resource usage and performance. ApsaraDB for PolarDB offers six times the performance of traditional MySQL database engines in handling large amounts of concurrent queries. Each node can handle up to one million queries per second. It takes less than five minutes to scale out compute nodes. These features enable you to handle workload spikes with ease.

  • Data security and availability

    Each ApsaraDB for PolarDB cluster consists of one primary (read/write) node and multiple secondary (read-only) nodes that share the same data replica. This greatly reduces storage costs. ApsaraDB for PolarDB also supports primary/secondary switchover with zero data loss. This resolves the issue of data inconsistency between the read-only and read/write nodes caused by asynchronous replication. It takes only a few minutes to add read-only nodes, back up data, and restore data.

  • Highly compatible with database engines

    ApsaraDB for PolarDB provides three independent database engines: one is 100% compatible with MySQL, one is 100% compatible with PostgreSQL, and one is highly compatible with Oracle. You can migrate data from any of these engines to the Alibaba Cloud enterprise database platform without making changes to any of the code.

What features does ApsaraDB for PolarDB provide?

How it works

ApsaraDB for PolarDB provides the following features:

  • Decoupled compute and storage
    • Compute nodes (DB servers): execute SQL statements, read data, and write data.
    • Storage nodes (data chunk servers): store data and database snapshots. Storage nodes are grouped into clusters.

    Decoupling compute and storage means that the compute and storage nodes no longer compete for compute (CPUs and memory) and storage (disks) resources. Additionally, ApsaraDB for PolarDB has optimized the performance of CPUs and memory to improve resource usage and reduced the costs of storage.

    Compute nodes and storage nodes are interconnected through remote direct memory access (RDMA) to ensure efficient data transmission.

    When you purchase a traditional database, you must specify the disk size. With compute and storage decoupled in ApsaraDB for PolarDB, however, you can purchase storage resources separately by using the pay-as-you-go billing method or by choosing a storage package whose specifications meet your needs. If you want to add a read-only node, you only need to pay for the compute resources you use. No additional storage fees are incurred.

  • Shared storage

    In a traditional database cluster, each node maintains a data replica. In an ApsaraDB for PolarDB cluster, all nodes (including the read/write node and the corresponding read-only nodes) share the same data replica stored on storage nodes. When you add a read-only node, you do not need to replicate data. Read-only nodes can be created in a short amount of time, and you only need to pay for a node.

  • RDMA technology and backup optimization

    ApsaraDB for PolarDB leverages RDMA and Paxos block storage to completely back up data in only a few seconds. If a node fails, you can restart the database process to resume the service.

    ApsaraDB for PolarDB supports copy-on-write. This technology enables you to create a snapshot in a few seconds or create a full copy of data in a few minutes. This technology is supported for disks up to 100 TB.

Quick migration from ApsaraDB for RDS to ApsaraDB for PolarDB

ApsaraDB for PolarDB supports data migration from RDS for MySQL 5.6 databases to ApsaraDB for PolarDB clusters. For more information, see Upgrade RDS MySQL to POLARDB for MySQL with one click.

Why is ApsaraDB for PolarDB better than other traditional database engines?

  • When you purchase a traditional database cluster, you must specify the storage capacity you want to purchase. Typically, the storage capacity cannot be greater than 3 TB. If the 3-TB storage capacity is used up, it may take more than a day to expand it. An ApsaraDB for PolarDB cluster is served by a storage cluster. The disks in the storage cluster can be dynamically expanded. The disk expansion process is transparent to users, and you do not need to stop the ApsaraDB for PolarDB cluster during this process.
  • Traditional database engines require you to replicate data when adding read-only nodes. The scale-out speed depends on how much time the data replication takes. Each ApsaraDB for PolarDB cluster has one read-only node after being created and allows all the nodes in it to share the same data replica on the serving storage cluster. You can add read-only nodes to the ApsaraDB for PolarDB cluster in only a few minutes without the need to replicate data.
  • In a traditional database cluster, the read/write and read-only nodes each have their own data replicas. You have to pay for both compute and storage resources when purchasing read-only nodes. ApsaraDB for PolarDB uses the pay-as-you-go billing method, therefore you only need to pay for the storage resources you actually use.

How is ApsaraDB for PolarDB priced?

For more information about ApsaraDB for PolarDB pricing, see Specifications and pricing.

Are compute and storage decoupled in ApsaraDB for PolarDB?

Yes, compute and storage are decoupled in ApsaraDB for PolarDB. This compute and storage decoupled architecture improves user experience for high availability, data backup and restoration, and scalability.

What is the maximum data volume supported by ApsaraDB for PolarDB?

Each ApsaraDB for PolarDB cluster supports a data volume of up to 100 TB.

How does ApsaraDB for PolarDB perform an automatic failover?

Each ApsaraDB for PolarDB cluster you purchase consists of one primary node and one read-only node by default. You can purchase more read-only nodes after you have created a cluster. If the primary node fails, the system automatically promotes the read-only node with the highest failover priority to become the new primary node while restoring the faulty node. If a read-only node fails, the system automatically switches the services on the faulty node to another read-only node while restoring the faulty node.

How does ApsaraDB for PolarDB back up data?

ApsaraDB for PolarDB uses snapshots to back up data.

How many read-only nodes does an ApsaraDB for PolarDB cluster support?

An ApsaraDB for PolarDB cluster supports up to 15 read-only nodes.

How long does it take to create a read-only node in an ApsaraDB for PolarDB cluster?

Thanks to the compute and storage decoupled architecture, it takes less than 5 minutes to create a read-only node in an ApsaraDB for PolarDB cluster regardless of your data volume.

What technology is used in ApsaraDB for PolarDB to guarantee high-speed network access?

ApsaraDB for PolarDB uses dual-port RDMA technology to guarantee high I/O throughput between DB servers and data chunk servers, and between data replicas. Each port can deliver up to 25 Gbit/s at low latency.