How to migrate to a new a cluster via restore

This page contains the steps needed to prepare for and perform a restore of a backup from a different cluster, i.e. cluster migration via restore.

We will use the following terms:

• new cluster - the backed-up cluster that we will migrate data from.
• old cluster - the currently active cluster that will be restored to the state of the new cluster.

Prerequisites

• For bare replica sets:
  • The new cluster has a number of replicas equal to or greater than the old cluster.
    • E.g. Your old cluster had 2 replicas, so your new cluster must have 2 or more replicas
  • See How To > Scale replicas and shards
• For sharded clusters:
  • The new cluster has a number of shards and replicas equal to or greater than those in the old cluster.
    • E.g. Your old cluster had 2 shards, so your new cluster must have 2 or more shards.
    • E.g. Your old shard had 4 replicas, so your new shard must have 4 or more replicas.
  • See How To > Scale replicas and shards
• Configured settings for S3 storage
  • See How To > Configure S3
• Backups from the new cluster in your S3 storage
• Password from your new cluster

Summary

• Change password of old cluster
• List all backups
• Define remap pattern (sharded cluster only)
• Restore backup

---

Change password of old cluster

The migration process will restore the password from the new cluster to your old cluster. Set the password of your old cluster to the new cluster’s password:

juju run <replica-set name | config-server name>/leader set-password password=<new cluster password>

List all backups

To view the available backups, enter the command list-backups:

juju run <replica-set name | config-server name>/leader list-backups

This shows a list of the available backups similar to the output below. Identify which backup-id corresponds to the new cluster.

    backup-id             | backup-type  | backup-status
    ----------------------------------------------------
    YYYY-MM-DDTHH:MM:SSZ  | logical      | finished 

Define remap pattern (sharded cluster only)

If you are running Charmed MongoDB K8s as a bare replica set, you can skip this step.

A remap pattern is a pattern that specifies which old components should be migrated to which new components. They are used when we are migrating to a cluster with new names.

The following example shows how to create a remap pattern for a sample cluster migration.

Sample old cluster:

Model    Controller  Cloud/Region         Version  SLA          Timestamp
old-mod  overlord    localhost/localhost  3.1.6    unsupported  17:27:22Z

App            Version  Status   Scale  Charm       Channel  Rev  Exposed  Message
application             active       1  application            0  no
config-server           active       1  mongodb-k8s                0  no
shard-one               active       1  mongodb-k8s                1  no
shard-two               active       1  mongodb-k8s                2  no

Unit                         Workload  Agent  Machine  Public address  Ports            Message
application/0*               active    idle   4        10.130.84.77
config-server/0*             active    idle   0        10.130.84.120   27017-27018/tcp
self-signed-certificates/0*  active    idle   3        10.130.84.32
shard-one/0*                 active    idle   1        10.130.84.78    27017/tcp
shard-two/0*                 active    idle   2        10.130.84.68    27017/tcp

Sample new cluster:

Model    Controller  Cloud/Region         Version  SLA          Timestamp
new-mod  overlord    localhost/localhost  3.1.6    unsupported  17:27:22Z

App               Version  Status   Scale  Charm        Channel  Rev  Exposed  Message
application                active       1  application             0  no
config-server-new          active       1  mongodb-k8s                 0  no
shard-one-new              active       1  mongodb-k8s                 1  no
shard-two-new              active       1  mongodb-k8s                 2  no

Unit                         Workload  Agent  Machine  Public address  Ports            Message
application/0*               active    idle   4        10.130.84.77
config-server-new/0*         active    idle   0        10.130.84.120   27017-27018/tcp
self-signed-certificates/0*  active    idle   3        10.130.84.32
shard-one-new/0*             active    idle   1        10.130.84.78    27017/tcp
shard-two-new/0*             active    idle   2        10.130.84.68    27017/tcp

The following would be a valid remap pattern:

config-server-new=config-server,shard-one-new=shard-one,shard-two-new=shard-two

Restore backup

To restore your current cluster to the state of the previous cluster, run the restore command and pass the correct backup-id to the command:

juju run <replica-set name | config-server name>/leader restore backup-id=YYYY-MM-DDTHH:MM:SSZ [remap-pattern=<remap-pattern>]

Your restore will then be in progress. Once it is complete, your old cluster will represent the state of the new cluster.

---