If you are managing a production database, chances are high that you’ve had to clone your database to a different server than the production server. The basic method of creating a clone is to restore a database from a recent backup on to a different database server. Other methods include replicating from a source database while it is up, in which case it is important the original database be unaffected by any cloning procedure.
A cloned database is useful in a number of scenarios:
- Troubleshoot your cloned production cluster in the safety of your test environment while performing destructive operations on the database.
- Patch/upgrade test of a cloned database to validate the upgrade process before applying it to the production cluster.
- Validate backup & recovery of a production cluster using a cloned cluster.
- Validate or test new applications on a cloned production cluster before deploying it on the live production cluster.
- Quickly clone the database for audit or information compliance requirements for example by quarter or year end where the content of the database must not be changed.
- A reporting database can be created at intervals in order to avoid data changes during the report generations.
- Migrate a database to new servers or a new data center.
Cloning a Galera Cluster for MySQL
One of the cool new features in ClusterControl allows you to quickly clone, in one click, an existing Galera cluster so you have an exact copy of the database.
Let us assume we have a cluster A that we we want to clone.
The steps are:
- Select the number of nodes in your cloned cluster.
- Decide whether the cloned cluster will be “attached” to A, i.e., the clone will get updates that are made to A. One benefit of doing this is to keep the clone in sync with A, e.g. during a live migration.
- Click on ‘Create Clone’.
When viewing your list of clusters in the ClusterControl UI, you will see a "Clone" button next to your deployed Galera Clusters.
Click on the "Clone" button. Select the target DB host/node for the cloned cluster to start with, the size of the cloned cluster, the cluster name and whether to automatically detach the cloned cluster from the source cluster once created.
Until the cloned cluster is actually "detached" from the source cluster, it continues to receive updates. Once detached, the clone is totally separated from the source cluster.
A cloned cluster that has not yet been detached from its source cluster is marked with a red border as seen below. You can at anytime move DB nodes back and forth between the clusters if you want to rearrange your DB hosts to a specific cluster.
Click on 'Detach' to break the link between the origin and its cloned cluster. The red border will dissapear and you have two separate and independent clusters.
You can now perform any operations on your cloned cluster without disrupting or jeopardizing your production cluster.