You can deploy OCP clusters in the multi-cluster mode. This mode implements a high-availability redundancy architecture based on two IDCs and provides more reliable cluster management and monitoring services.
Applicability
This topic applies only to OceanBase Cloud Platform Enterprise Edition. OceanBase Cloud Platform Community Edition does not support the multi-cluster mode.
Features
In the multi-cluster mode, you can deploy multiple OCP clusters remotely to manage primary and standby OceanBase clusters across two or more cities. You can manage primary and standby OceanBase clusters across OCP clusters, for example, create, delete, and update primary and standby OceanBase clusters, as well as switch an OceanBase cluster in daily maintenance or a failover.
In the multi-cluster mode, you can switch the roles of leader and follower OCP clusters upon a network failure. When an OCP cluster fails, the operation and maintenance of OceanBase clusters managed by other OCP clusters are not affected. In multi-cluster mode, you can register and bind OCP clusters and switch an OCP cluster in daily maintenance or a failover. For more information, see Switch an OCP cluster in daily maintenance and Switch an OCP cluster in a failover. Related concepts:
An OCP cluster is the minimum unit for managing OceanBase clusters. An OceanBase cluster can be managed by only one OCP cluster. An OCP cluster can span one or more zones.
A multi-zone mode is a mode in which an OCP cluster spans multiple zones.
Architecture
The OCP multi-cluster mode applies to scenarios where two or three IDCs are deployed across two or more cities. Principles:
Two IDCs across two or more cities
When the primary and standby OceanBase clusters are deployed in two cities, you can deploy OCP clusters in two IDCs across these two cities. When the OCP cluster in one city fails, the other OCP cluster manages the operation, maintenance, monitoring, and alerts of the OceanBase clusters.
Assume that your OCP clusters are deployed in Cities 1 and 2. The OCP cluster in City 1 serves as the leader and those in City 2 serve as followers. The leader and follower OCP clusters manage multiple OceanBase clusters.
When the two cities are disconnected due to a network failure, the backup OCP cluster can switch to be the leader in a failover. In this case, City 1 and City 2 both have a leader cluster. Each leader OCP cluster monitors the operation and maintenance of the primary OceanBase cluster managed by it. You must delete the data of the standby OceanBase cluster that is not bound to the primary OceanBase cluster managed by the current leader OCP cluster. For more information, see Switch an OCP cluster in a failover.
The application accesses an OceanBase cluster through OBProxy. For the primary and standby OceanBase clusters that are managed across OCP clusters, each OceanBase cluster is bound to an OBProxy. You can access a standby OceanBase cluster through the OBProxy bound to it. When the leader and follower OCP clusters fail, the application can still access a standby OceanBase cluster through the OBProxy bound to it.
Note
If an OBProxy is bound only to a standby OceanBase cluster, you must add the standby cluster ID to the username when you access the standby cluster through the OBProxy, for example, mysql -h xxx.xxx.xxx.xxx -P 2881 -u root@tenant#obcluster:1000 -p ****. The cluster ID is also displayed in the connection string of the OCP cluster. If the ID is removed, you cannot connect to the standby OceanBase cluster.
After the network recovers, you have two leader OCP clusters that run independently of each other. You can switch one of them to a follower and bind it to the leader through OCP cluster registration registration. For more information, see Register an OCP cluster.

Three IDCs across two or more cities
In the multi-cluster mode, you can deploy multiple OCP clusters across two or more zones. Assume that you have three IDCs in two cities: City 1 and City 2. You have deployed three clusters in these two cities: one in City 1 as the leader and the two in City 2 serve as followers. The leader and follower OCP clusters manage multiple OceanBase clusters.
When the two cities are disconnected due to a network failure, you can select one of the follower OCP clusters and switch it to a leader in a failover. In this case, City 1 runs one leader, and City 2 runs one leader and two followers.
Each leader OCP cluster monitors the operation and maintenance of the primary OceanBase cluster managed by it. You must delete the data of the standby OceanBase cluster that is not bound to the primary OceanBase cluster managed by the OCP cluster of the current leader. For more information, see Switch an OCP cluster in a failover.
The application accesses an OceanBase cluster through OBProxy. For the primary and standby OceanBase clusters that are managed across OCP clusters, each OceanBase cluster is bound to an OBProxy. You can access a standby OceanBase cluster through the OBProxy bound to it. When the leader and follower OCP clusters fail, the application can still access a standby OceanBase cluster through the OBProxy bound to it.
Note
If an OBProxy is bound only to a standby OceanBase cluster, you must add the standby cluster ID to the username when you access the standby cluster through the OBProxy, for example, mysql -h xxx.xxx.xxx.xxx -P 2881 -u root@tenant#obcluster:1000 -p ****. The cluster ID is also displayed in the connection string of the OCP cluster. If the ID is removed, you cannot connect to the standby OceanBase cluster.
After the network recovers, the follower OCP cluster in City 2 appears in the OCPs list of City 1, but it is bound to the leader OCP cluster in City 2. In this case, you can unbind the follower OCP cluster to remove it from the OCP cluster list of City 1. For more information, see Delete an OCP cluster.
To bind the original leader OCP cluster to the current leader OCP cluster, you must clear data of the original leader OCP.

Management of multiple OCP clusters
The following table describes the operations you can perform to manage multiple OCP clusters.
| Operation | Description |
|---|---|
| Register an OCP cluster | You can perform this operation to bind a follower OCP cluster to the leader OCP cluster. |
| View Leader/Follower Details page | You can perform this operation to view the details of the leader and follower OCP clusters. |
| Manage OCP cluster parameters | You can perform this operation to view and modify the parameters of multiple OCP clusters. |
| Switch an OCP cluster in daily maintenance | You can perform this operation to perform daily switchover between the leader and follower OCP clusters. |
| Switch an OCP cluster in a failover | You can perform this operation to switch OCP clusters for disaster recovery. |
| Delete an OCP cluster | You can perform this operation to delete a follower OCP cluster with a heartbeat timeout exception from the cluster. |
| Unbind OCP clusters | You can perform this operation to unbind an OCP cluster from a cluster of multiple OCP clusters. |