Deploy and Failover to Secondary Cluster

In this article, we explore how to deploy a secondary cluster and failover with ClusterControl. A secondary cluster provides high availability and disaster recovery, ensuring minimal downtime in case of primary cluster failure.

Use cases

Deploying and failing over to a secondary cluster is useful in the following scenarios:

• Ensuring high availability in case of primary cluster failure.
• Implementing disaster recovery strategies for business continuity.
• Performing planned maintenance without downtime.
• Distributing read traffic across multiple clusters.
• Enabling quick recovery from unexpected infrastructure issues.

Deploying a Secondary Cluster

To deploy a Secondary Cluster from ClusterControl, first, you need to have a Primary cluster in place.

For this, follow the corresponding instructions here: Create Database Cluster.

After you have the Primary cluster deployed, go to ClusterControl GUI → Clusters → Cluster Actions → Clone/Replicate the cluster → Create replica cluster.

There, you can choose if you want to get data from a primary cluster or from an existing backup.

Replicate from Primary

1. When replicating from a primary cluster, choose the node from where you are going to replicate data from and specify if it is a bidirectional replication.
2. Configure the SSH credentials and security configuration.
3. Specify the node configuration like server port, data directory, version, etc.
4. Add the node IP address or hostname to be added to the secondary cluster.

Replicate from Backups

1. When replicating from backups, choose the backup to be restored in the new cluster and specify if it is a bidirectional replication.
2. Configure the SSH credentials and security configuration.
3. Specify the node configuration like server port, data directory, version, etc.
4. Add the node IP address or hostname to be added to the secondary cluster.

Clone cluster

In case you don't want to have the latest data replicated to the new cluster, you can just clone the existing cluster and keep it as a separated cluster for testing or datawarehousing.

For this, after you have the primary cluster deployed, go to ClusterControl → Clusters → Cluster Actions → Clone/Replicate the cluster → Clone cluster.

This will create a exact copy of the primary cluster without configuring a replication between the primary and the new cluster.

Failover

To failover to the Secondary cluster, you need to disable read-only to be able to write data on it, and change the endpoint to use the new cluster.

Note

If you are using a load balancer, depending on the configuration, most probably the endpoint change won't be necessary.

When the Primary cluster is back, if the replication configured between the clusters was bi-directional, the cluster will get the latest data when the replication lag reach 0. Otherwise, you have to rebuild the Primary cluster from the Secondary one and enable read-only after failover back, then update the endpoint again.

Cluster Replication Status using CLI

To see the Cluster replication status in the CLI, run:

s9s replication --list --long

You will get an output like this:

CID     SLAVE               MASTER              STATUS  MASTER_CLUSTER  LAG
1       10.10.10.122:3306   10.10.10.125:3306   Online  3               0
3       10.10.10.125:3306   10.10.10.122:3306   Online  1               0
Total: 2 replication link(s)