PolarDB:Multi-master Cluster (Database/Table) Commercial Release

Overview

As more large-scale enterprise customers adopt PolarDB for MySQL, some run massive workloads. In specific scenarios, the current single-writer (one-writer, multiple-readers) architecture of PolarDB for MySQL can encounter a write performance bottleneck.

PolarDB for MySQL introduces the new multi-master cluster (database/table). This upgrade shifts the architecture from one-writer, multiple-readers to a multi-writer, multi-reader architecture. It targets high-concurrency read-write scenarios such as Multitenancy in SaaS, gaming, and E-commerce.

Key Benefits and Capabilities

• Second-level horizontal write scaling

  Supports concurrent writes to different databases or tables across separate compute nodes. Up to 32 nodes can write simultaneously. Databases can be dynamically relocated across compute nodes in seconds. This capability greatly improves the overall concurrent read-write throughput.

• Multi-master backup (no dedicated standby nodes)

  If a primary node fails, traffic switches to another low-traffic primary node in seconds. Because no idle resources are reserved for hot standby, costs are reduced by 50%.

• Global read-only nodes

  You can read all data written by any writer node on global read-only nodes. This simplifies aggregation queries.

Scenarios

The multi-master cluster (database/table) is designed for high-concurrency read-write scenarios such as Multitenancy in SaaS, gaming, and E-commerce.

• Multitenancy in SaaS: Meet high-concurrency demands and balance tenant load

Scenario characteristics: The number of tenant databases changes rapidly, and workloads fluctuate widely. You must frequently reallocate database resources across instances to deliver an optimal user experience.

Solution: The multi-master cluster (database/table) lets you switch tenant databases across RW nodes in seconds or add new RW nodes in seconds to absorb burst traffic. This achieves load balancing.

• Global-server gaming and E-commerce: Scale in minutes to match surging demand

Scenario characteristics: Global-server gaming and E-commerce typically use sharding solutions based on middleware or application logic. During version updates or sales promotions, you often need to increase cluster capacity severalfold and then quickly scale back down after the event ends. Traditional clusters require data migration during scaling, which is a complex process.

Solution: The multi-master cluster (database/table) supports second-level horizontal scaling and transparent routing. When combined with middleware or application-based sharding, it enables transparent, second-level scaling. This reduces scaling time from days to minutes.

• Regional-server gaming: Better performance and flexibility for scaling

Scenario characteristics: During the growth phase of a game, the database load steadily increases. You add more databases over time, which increases the load on RW nodes. During the decline phase of a game, the database load drops. You can merge databases to reduce the load on RW nodes.

Solution: During the growth phase, you can shift some databases to new RW nodes to balance the load. During the decline phase, you can consolidate databases onto fewer RW nodes to reduce operational costs.

• Data aggregation: Lower-cost, simpler aggregation across multiple write nodes

Scenario characteristics: In traditional architectures, you deploy multiple independent frontend clusters to handle Online Transaction Processing (OLTP) read-write requests. A separate aggregation cluster collects data from all frontend clusters. Data sync tools such as DTS periodically replicate data between the frontend clusters and the aggregation cluster. Each component, including the frontend clusters, aggregation cluster, and DTS, adds cost and complexity.

Solution: You can migrate frontend clusters to the multi-master cluster (database/table) and add compute nodes as needed. You can use global read-only nodes in the multi-master cluster (database/table) as your aggregation layer. This eliminates replication latency for aggregation workloads. It also removes the need for extra storage and compute resources for the aggregation cluster. Overall costs are reduced by two-thirds.

Architecture Diagram

The following figure shows the architecture of the multi-master cluster (database/table).

Version Requirements

The multi-master cluster (database/table) requires PolarDB for MySQL kernel version 8.0.

Performance Improvements

Tests show that as more databases in a cluster are distributed across additional primary (RW) nodes, the cluster’s overall concurrent read-write throughput increases in a nearly linear manner.

The actual test results are described below.

• Test background: The test was performed on a cluster that contains eight databases and eight RW nodes.

• Test procedure: Initially, all eight databases were running on a single RW node. Then, identical stress tests were run on all databases. During the tests, the databases were evenly redistributed across two, four, and finally eight RW nodes. The cluster-wide performance trends were observed at each step.

• Performance trend (Queries Per Second (QPS) example): As shown in the chart, distributing databases across more RW nodes significantly increases the overall concurrent read-write throughput in a nearly linear fashion.

References

• Multi-master Cluster (Database/Table)

• Usage Instructions