PolarDB-X, X-DB, and PolarDB

This article introduces PolarDB-X, X-DB, and PolarDB, and discusses their relationships and capabilities in terms of disaster recovery, horizontal scaling, and cloud-native features.

By Mengshi

PolarDB-X, X-DB, and PolarDB are all database products developed by Alibaba.

Let's take a closer look at their relationship.

What is X-DB?

Firstly, we need to understand what X-DB is. In short, X-DB is a highly available distributed database built on MySQL, using the XEngine. It can operate across availability zones (AZ).

One of the core capabilities of X-DB is achieving a cross-AZ RPO of 0 based on Paxos. Initially, Alibaba used MySQL in a traditional primary/secondary architecture, with each MySQL instance consisting of two nodes.

This architecture had a significant flaw; if a primary/secondary switchover occurred, it might lead to inconsistent replica data. To address this, Alibaba used a variety of operational means to tackle these issues, including:

Application High Availability Service (ADHA): A system designed to check whether a node is normal and perform primary-secondary switchovers in MySQL services.
Data verification: Conducting complex data checks before switching to ensure consistency between primary and secondary nodes. (What if data is inconsistent?)
Data synchronization: Using a data synchronization service developed by Alibaba Cloud instead of the synchronization mechanism of MySQL in cross-city scenarios.
Data correction: Using a sophisticated data correction program to roll back and supplement service data (This program imposes specific requirements on the service table structure.)

Although this architecture worked, it was not an elegant solution. It was highly complex and expensive to maintain, making it challenging to keep up with the growth of services.

In 2016, Alibaba began developing X-DB. The primary goal of X-DB was to ensure data consistency across replicas. The X-DB team chose to develop their own Paxos protocol to replace MySQL's master-slave replication mechanism. For more information on Paxos, there are numerous articles available online.

Here are two main advantages of using the Paxos protocol with MySQL: 1. You can perform a switchover at any time without causing data inconsistency (RPO=0). 2. Leader election and failure detection are completed within the X-DB kernel (MySQL process), without needing any external systems.

After several years of development at Alibaba, the Paxos protocol of X-DB combined with MySQL has completely replaced traditional master-slave MySQL clusters, offering high reliability.

PolarDB-X and X-DB

While X-DB addresses disaster recovery and failback issues, PolarDB-X stands out for its versatility in service scenarios and its horizontal scaling abilities.

PolarDB-X 2.0 integrates the cluster disaster recovery technology of X-DB into its data nodes and provides horizontal scaling abilities.

In the industry, many distributed databases use protocols such as Paxos to build data nodes. For example, TiKV uses the Raft protocol, and OceanBase uses the Paxos protocol.

The following figure shows the three-replica mechanism of TiKV.

The relationship between X-DB and PolarDB-X extends beyond the Paxos protocol. Significant development work has been done in areas such as distributed transactions, scalability, computing pushdown, and HTAP. Stay tuned for our upcoming articles for more information.

PolarDB-X and PolarDB

PolarDB (specifically PolarDB for MySQL) is a cloud-native database that uses shared storage technology. This allows for highly elastic storage space, but typically, its computing and writing capabilities are limited by the capacity of a single machine.

PolarDB-X 2.0, on the other hand, uses a shared-nothing architecture. This means that all resources, including computing, writing, reading, and storage, can scale horizontally, which avoids single-machine bottlenecks.

However, this architecture is less flexible in terms of pure data capacity compared to the shared storage architecture of PolarDB.

For instance, with any shared-nothing database such as PolarDB-X 2.0 or TiDB, if you have 10 machines with 10 TB of data and want to expand storage by adding more machines, half of the data needs to be moved to the new machines. The time required for this migration is directly proportional to the amount of data. Generally, it can take several hours to move tens of terabytes of data.

In contrast, with PolarDB, such scaling can be completed in minutes.

Can we combine the benefits of shared-nothing and shared-storage/shared-everything architectures?

The answer is yes.

The next-generation distributed databases integrate the core technology of PolarDB, which leverages RDMA hardware and a shared storage architecture, into the data nodes. This integration allows for horizontal scaling of all resources and significantly reduces the costs associated with capacity elasticity.

In the future, the local disk version and shared storage version of PolarDB-X will coexist. The local disk version does not require special hardware. Therefore, this version is ideal for lightweight deployment on private clouds, targeting delivery with just three machines. On the other hand, the shared storage version offers highly elastic capacity, which is best utilized on a public cloud where a large pool of machines is available for scaling.

Try out database products for free:

Community

PolarDB-X, X-DB, and PolarDB

What is X-DB?

PolarDB-X and X-DB

PolarDB-X and PolarDB

Read previous post:

Read next post:

ApsaraDB

You may also like

Comments

ApsaraDB

Related Products

PolarDB for PostgreSQL

PolarDB for Xscale

PolarDB for MySQL

Database for FinTech Solution