PolarDB:Multi-master Cluster (Limitless)

The following figure shows the architecture of Multi-master Cluster (Limitless) Edition.

Multi-master Cluster (Limitless) Edition is suitable for scenarios such as multitenancy in SaaS, gaming, and e-commerce. These scenarios feature high-concurrency 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: Multi-master Cluster (Limitless) Edition helps customers switch between different primary nodes of databases of tenants or add new primary nodes in seconds to process burst traffic. This implements load balancing.

• Global gaming server and e-commerce scenarios: scaling in minutes to cater to fast-growing business requests

  Scenario: The middleware-based or business-based database and table sharding solution is often used. During version updates and major promotions, sharp scale-out of cluster capacity is required. Quick scale-in is necessary when version updates and major promotions end. However, the scaling of traditional clusters involves complex steps for data migration.

  Solution: The scale-out in seconds and transparent routing features of Multi-master Cluster (Limitless) Edition can be used together with the middleware-based or business-based database and table sharding solution to shorten the scale-out process from several days to several minutes.

• Gaming applications deployed on different servers: better performance and scalability

  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 primary 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.

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 code snippet provides an example of stress testing:

• 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.