Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

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. 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
  • Backups from the new cluster in your S3 storage
  • Password from your new cluster

Summary

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 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.

If you are running Charmed MongoDB as a sharded cluster and you wish to migrate to a cluster with new names, you must generate a remap pattern.

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                0  no
shard-one               active       1  mongodb                1  no
shard-two               active       1  mongodb                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                 0  no
shard-one-new              active       1  mongodb                 1  no
shard-two-new              active       1  mongodb                 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.

Previous Restore a backup Next Minor version upgrades

Last updated 27 days ago. Help improve this document in the forum.