This page covers common questions about PolarDB for MySQL Multi-master Cluster (Limitless) Edition, including node management, connection behavior, data isolation, cross-node operations, and recovery.
Key limitations at a glance
Before using the Multi-master Cluster (Limitless) Edition, be aware of these constraints:
Area | Limitation |
Minimum nodes | A cluster requires at least two read/write nodes. You cannot delete a node if only two remain. |
Cross-node transactions | All databases and data objects modified within a single transaction must be on the same node. |
Data access per node | Data within a single database or data object can be accessed on only one node at a time. |
Endpoint switching | Switch endpoints during off-peak hours to reduce the risk of slow ALTER statements. |
Node management
How do I add more read/write nodes?
A new cluster starts with two read/write nodes. You can add more after the cluster is created. See Add or remove nodes.
What should I do before deleting a read/write node?
Migrate the endpoints of all databases on that node to other available read/write nodes first. If you skip this step, those databases become inaccessible.
A cluster requires at least two read/write nodes. You cannot delete a node if only two remain.
See Delete a node for step-by-step instructions.
I deleted a read/write node without migrating its databases. How do I recover?
Run the following SQL statement to reassign the inaccessible database to an active read/write node:
ALTER DATABASE <name> POLARDB_WRITE_NODE <new_master_id>;Replace <name> with the database name and <new_master_id> with the ID of the target node. For more details, see Instructions.
How do I add hot standby storage nodes?
Purchase hot standby storage nodes in the console. By default, they deploy in a different zone from other nodes and have independent compute and storage resources.
Connections and routing
Why are the connections on an RW node high even when it has a low workload?
When your application connects through the cluster endpoint, the database proxy establishes connections to every RW node — so each node shows the same connection count regardless of its actual workload. Enable the thread pool feature to prevent a high number of connections from consuming database resources.
Do I need to change my application code?
No. The proxy layer automatically routes requests to the correct node based on which node owns the endpoint for a given database or data object. Your application does not need to know the underlying topology.
Data isolation and endpoints
Can I access data from any RW node?
No. Data within a single database or data object can be accessed on only one node at a time. Use a command to dynamically switch the endpoint if you need to move access to a different node.
When should I use database-level isolation versus object-level isolation?
Use database-level isolation (the default) when your services are organized by database or schema and cross-database queries are rare. It simplifies endpoint management when you need to switch endpoints.
Use object-level isolation when your services share a few databases and feature boundaries align with individual tables or objects. It requires minimal application changes and gives you fine-grained control, but endpoint switches are more complex because you must switch each object individually.
Why does an ALTER statement to switch an endpoint take a long time?
Two situations cause this:
The database contains a large number of objects, which makes the switch inherently slower.
High Data Manipulation Language (DML) write pressure on the database or object during the switch delays completion.
Switch endpoints during off-peak hours to reduce the impact of both factors.
Cross-node operations
Can I modify two databases or objects in a single transaction if they are on different nodes?
No. All databases and data objects modified within a single transaction must be on the same node.
Solution: You can use a multi-master sharded table instead of performing related modifications across different nodes. A multi-master sharded table automatically distributes data across multiple sharded databases based on sharding rules. This enables read/write operations on each node and provides distributed processing capabilities.
If your workload requires writes across multiple nodes, use a multi-master sharded table instead. It distributes data across multiple sharded databases based on sharding rules, enabling read/write operations across nodes with automatic distributed processing.
Can I run a query that spans databases or objects on different nodes?
Yes. Purchase a global read-only node, which lets you query across endpoints on different nodes.
Metadata and binlogs
How do I view metadata?
Use the tables in information_schema as usual, but be aware of scope:
Table | Scope |
| Cluster-wide information |
| Information for the specific node executing the query |
How do I subscribe to binlogs with multiple write nodes?
Enable binlogs for the cluster. The downstream application can then subscribe directly using the cluster endpoint. The Multi-master Cluster (Limitless) Edition automatically sorts the logs and provides a single, coherent binlog stream for the downstream application.