To address the write performance bottlenecks of the one-write-multiple-read architecture, PolarDB for MySQL launched Multi-master Cluster (Limitless). This cluster upgrades the architecture from one write and multiple reads to multiple writes and multiple reads through multiple primary nodes. This solution is mainly designed for high-concurrency read/write application scenarios such as SaaS multi-tenancy, gaming, and e-commerce.
Product architecture
All data files of a cluster are stored in the shared storage (PolarStore). Each read/write (RW) node shares the data files in the underlying storage (PolarStore) through the distributed file system (PolarFileSystem). You can access the entire cluster through the cluster endpoint, and the database proxy automatically forwards SQL statements to the correct RW node.
Core advantages and capabilities
Horizontal write scale-out in seconds
Different databases/tables can be written concurrently on different compute nodes, and up to 63 nodes can write data at the same time. Different databases can be dynamically scheduled across different compute nodes within seconds, which greatly improves the overall concurrent read/write capability.
Multi-master mutual backup (no standby nodes required)
If a primary node fails, workloads can be switched to another low-traffic primary node within seconds. In addition, because there are no additional idle resources reserved for hot standby, the cost is reduced by half.
Global Read-Only Node
You can read the data of all write nodes on the global read-only node, which makes it convenient to run aggregation queries. For more information, see Global read-only nodes.
Scenarios
Multi-master Cluster (Limitless) Edition is mainly designed for high-concurrency read/write application scenarios such as SaaS multi-tenancy, gaming, and e-commerce.
SaaS multi-tenancy scenario: meets high-concurrency performance requirements and achieves load balancing between tenants
Scenario characteristics: The number of tenant databases changes rapidly and the load fluctuates greatly. Database resources need to be frequently reallocated between different instances to achieve the best user experience.
Solution: Multi-master Cluster (Limitless) Edition can switch tenant databases between different RW nodes within seconds, or add new RW nodes within seconds to handle burst traffic, thereby achieving load balancing.
World-server gaming and e-commerce scenario: scaling in and out within minutes to adapt to rapidly growing business requests
Scenario characteristics: World-server gaming and e-commerce scenarios usually adopt middleware-based or business-based database and table sharding solutions. During version updates and big sales events, the cluster capacity often needs to be quickly scaled out by several times, and quickly scaled back in after the events end. However, scaling traditional clusters in or out requires data migration, which is very complex.
Solution: With the horizontal scale-out in seconds and transparent routing features of Multi-master Cluster (Limitless) Edition, combined with middleware-based or business-based database and table sharding, transparent scale-out within seconds can be achieved, shortening the scale-out time from days to minutes.
Server-split gaming scenario: better performance and scalability, flexible scaling in and out
Scenario characteristics: During the growth period of a game, the database load is heavy and keeps growing. Typically, databases are continuously added during the growth period, which also increases the load on RW nodes. During the decline period, the database load gradually decreases and databases are continuously merged, so the load on RW nodes also shows a downward trend.
Solution: During the growth period of a game, some databases can be quickly switched to new RW nodes to achieve load balancing. During the decline period, databases can be quickly consolidated onto a small number of RW nodes to rapidly reduce operating costs.
Scope of application
The database engine is MySQL 8.0.
Direct conversion from Cluster Edition to Multi-master Cluster (Limitless) is currently not supported. To upgrade the product series, see Major version upgrades.
Performance improvements
Tests show that as the databases in a cluster are switched to more primary nodes (RW nodes), the overall concurrent read/write capability of the cluster improves almost linearly. The following is a test example:
Test background: The cluster contains eight databases and eight RW nodes.
Test procedure: Initially, all eight databases are loaded on one RW node, and then the same stress test is performed on all databases synchronously. During the stress test, the eight databases are evenly switched to two RW nodes, four RW nodes, and eight RW nodes respectively, and the overall performance change trend of the cluster is observed.
The performance change trend is as follows, taking QPS as an example:
As shown in the preceding figure, as databases are switched to more RW nodes, the overall concurrent read/write capability of the cluster is greatly improved, showing an almost linear increase.
Node specifications and pricing
Specifications: The Dedicated and General-purpose are supported. For specific specifications, see Compute node specifications for Enterprise Edition.
Pricing: For more information, see Compute nodes.
Getting started
Configure basic information for the cluster, such as creating a database account, Configure whitelists for a cluster, and connecting to a database.
Create a database. Multi-master Cluster (Limitless) restricts the data of each database or data object to be written by only one node. When you create a database, you can specify an RW node, or set the value of the
loose_innodb_mm_default_master_idparameter to 0 so that the system randomly selects an RW node to create the database.Query data by using
SELECTstatements. When you query data, you do not need to specify an RW node. The database proxy automatically selects the correct RW node to execute the query.
For more information, see Usage.