This topic describes the multi-master architecture that is soon to be released for the PolarDB for MySQL engine.
Overview
As the number of PolarDB for MySQL customers continues to increase, the number of tier-1 customers also increases. As the business volume of tier-1 customers grows increasingly larger, the PolarDB for MySQL architecture that consists of one write node and multiple read nodes faces challenges in write performance.
Therefore, PolarDB for MySQL is to release the multi-master architecture to upgrade the architecture from one write node and multiple read nodes to multiple write and read nodes. The new architecture is suitable for high concurrent read and write scenarios such as multitenancy, gaming, and e-commerce.
The following figure shows the multi-master architecture.
Core advantages
Different databases allow data to be written to different compute nodes.
Data can be written to up to 32 nodes at the same time.
Database resources can be dynamically scheduled across nodes. Business can be failed over within seconds. As a result, the overall concurrent read and write capabilities of clusters are improved.
If a compute node is faulty, business can be failed over within seconds.
Scenarios
The multi-master architecture is suitable for scenarios such as multitenancy in software as a service (SaaS), gaming, and e-commerce. These scenarios feature high concurrent read and write requests.
Multitenancy in SaaS: high concurrency and load balance between tenants
Scenario: The number of databases of tenants rapidly changes, and the load volume undergoes substantial changes. Users must schedule database resources among different instances to deliver optimal experience.
Solution: The multi-master architecture helps customers to switch between different read-only nodes of databases of tenants. This implements load balance.
Gaming applications deployed on different servers: better performance and scalability and global servers supported
Scenario: During the growth period of a game, database loads are heavy and feature continual increase. During this period, the number of databases keeps growing. As a result, the loads of primary nodes also increase. During the decline period of a game, database loads are significantly reduced, and databases are merged. As a result, the loads of read and write nodes are also decreased.
Solution: During the growth period, you can switch some databases to new primary nodes to implement load balance. During the decline period, you can aggregate databases to a few primary nodes to reduce operating costs.
Performance improvement
After tests, the overall concurrent read and write capabilities of a cluster show a linear increase because the databases of the cluster are switched to more primary nodes.
The following section describes the test data used in actual scenarios:
Test background: The cluster contains eight databases and eight primary nodes.
Test procedure: At the beginning of a test, eight databases share one primary node. Data is synchronized to all databases at the same time to perform the same stress test. During the stress testing period, eight databases are scheduled to two primary nodes, four primary nodes, and eight primary nodes respectively. View the change trend of the overall performance of the cluster.
The following figure shows the change trend of QPS.
In the preceding figure, as databases are scheduled to more primary nodes, the overall concurrent read and write capabilities of the cluster are significantly improved and show a linear increase.