What Is PolarDB?
PolarDB is the next-generation relational distributed database developed by Alibaba Cloud, which is 100% compatible with MySQL. Applications using MySQL could use PolarDB without modifying a line of code.
PolarDB runs in the form of a multi-node cluster, which includes a Writer node (master node) and multiple Reader nodes. The nodes share the same storage (PolarStore) at the bottom tier through a distributed file system (PolarFileSystem).
PolarDB provides services externally through an internal proxy tier, meaning that all applications go through this tier before accessing specific database nodes. Proxy does not only perform authentication and protection, but can also parse SQL, send write operations (such as transactions, Update, Insert, Delete, and DDL) to the Writer node, and distribute read operations (such as Select) to multiple Reader nodes in a balanced manner, which is also called Read/Write Splitting.
PolarDB provides two database addresses by default, one is cluster address and the other is primary address. It is recommended to use cluster address because it provides Read/Write Splitting function that integrates the resources of all nodes to provide services externally. The primary address is always pointed to the master node. SQL accessing the primary address is sent to the master node. When a master-slave switch (Failover) occurs, the primary address is automatically shifted to the new master node within 30 seconds to ensure that the application is always connected to the writable and readable master node.
As shown in the diagram above, the bottom tier is a storage tier to save costs, which is “integration”; The middle tier has multiple nodes to improve scalability, which is “splitting”; The upper tier is a proxy tier, which provides a unified portal for easy use, which is also “integration”. The “integration-splitting-integration” architecture maintains a balance between scalability and ease of use, making it as simple as using a single-point MySQL database for upper-tier applications.
Get Started in 10 Minutes
PolarDB is deployed in the cloud. When you create it, you need to choose the geographical availability zone and the specific VPC network to be used first, and then specify the number (from 2 to 16) of nodes and their configuration (from 2 cores to 88 cores). You do not have to configure storage space in advance, nor do you need to pay attention to the capacity size.The system automatically charges according to actual usage.
The creation process may last for 5–10 minutes, and then you can configure the whitelist and create a high-privilege account. And that’s it. You can create a logical DB and account User in the console, or you can log on to the database through a high-privilege account to execute SQL to create them.The results of the two methods are exactly the same.
DTS is recommended if you need to migrate the old database to PolarDB. Regardless of whether the source library is in MySQL built by RDS or ECS, or even in MySQL with public network address accessible under the cloud, online smooth migration can be done through DTS with downtime of 5–10 minutes.
In addition to using PolarDB like MySQL, it also has a few advantages that traditional MySQL databases do not have.
- Large Capacity
Capacity maximum is 100 T. It is no longer necessary to purchase multiple MySQL instances for sharding because of the upper capacity limit of a single machine. It is not even necessary to consider partitioning libraries and tables, thus simplifying application development and reducing the burden of operation and maintenance.
- Highly Cost-Effective
Multiple nodes charge only one share of storage cost, which means the more read-only instances, the more cost-effective.
- Minute-Level Elastic Scaling
The architecture that separates storage from computation, coupled with shared storage, makes rapid upgrade a reality.
- Read Consistency
The read-write splitting address of the cluster uses LSN (Log Sequence Numbers) to ensure the global consistency when reading data and to avoid inconsistent problems caused by master-slave delay.
- Millisecond-Level Delay — Physical Replication
Redo-based physical replication is used instead of Binlog-based logical replication to improve the efficiency and stability of master-slave replication. Even large table DDL operations with indexes and fields will not cause delay to the database.
- Unlocked Backup
Using the snapshot of the storage tier, the backup of the database with 2 T data can be completed in 60 seconds. And this backup process does not need to lock the database, which has almost no impact on the application and can be carried out 24 hours a day.
- Complex SQL Query Acceleration
Built-in parallel query engine has obvious acceleration effect on complex analysis SQL with execution time exceeding 1 minute. This function requires an additional link address.