Migrate between plans

Migrating between plans can be done in different ways depending on requirements and plans.

Change between shared plans

Go to the CloudAMQP Console and press Edit and change plan seamlessly. This change will not lead to changes in connection details and there will be no downtime.

Change between dedicated plans

To scale a cluster, go to the CloudAMQP Console and press Edit. Follow the steps to change plan and/or change number of nodes. You can add or remove nodes and change plan all together.
If you are running a multi-node cluster and are changing plan, we will change one node at a time. This means that you still can connect to the cluster during a change.
If you are running a single-node cluster and are changing plan, it will require some downtime. Try to keep your queues short to make the process of changing plan faster.

Change from shared to dedicated plan

The recommended process is to use rolling migration or queue federation for seamless migration, as described in the sections below.

Rolling migration

If seamless migration is not required, create a new instance and move your clients:

  1. Create a new instance
  2. Export definitions from old instance (if on a dedicated instance)
  3. Import definitions to new instance (if on a dedicated instance)
  4. Point your publishers to the new instance
  5. Allow consumers to empty the queues on the old instance
  6. Move consumers to the new instance
  7. Finish up by deleting the old instance

Copy settings

Settings such as definitions, alarms, integrations for metrics and logs, firewall rules, plugins and RabbitMQ config can be copied from one dedicated instance to another. When creating a new dedicated instance you will get the option to copy from an existing instance in step three of the process. Select the instance you want to copy from and what config you would like to copy. When the new instance is bootstrapped it will copy the configuration automatically.

Note that you will get a new connection string since the new instance will be on a different host with another hostname.

Note that it will not copy messages. You can use queue federation or shovel to move messages.

More details on the copy functionality in this blogpost.

Seamless migration with RabbitMQ queue federation

The RabbitMQ Federation plugin can be used when migrating to another cluster without stopping all producers and consumers while doing so. Make sure the plugin is enabled on upstream and downstream servers.

Queue federation connects an upstream queue and transfers messages to the downstream queue when there are consumers that have capacity on the downstream queue. Upstream servers are the servers on the message side where they are originally published. Downstream servers are where the messages get forwarded to.

upstream vs downstream

Consumers and publishers can be moved in any order. Messages are transferred to downstream queues when consumers are there. The downstream queue will only retrieve messages when it has run out of messages locally, when it has consumers that need messages, and/or when the upstream queue has "spare" messages that are not being consumed.

  1. Start by setting up the new instance which will be the downstream server.
  2. On the downstream server, create a policy that matches the queues to be federated.

    A policy is a pattern that queue names are matched against. The pattern is a regular expression used to match queue (or exchange) names. In this example, we are going tell the policy to federate all queues whose names begin with "metric.".

    Navigate to 'Admin' -> 'Policies' and press 'Add / update a policy' to create the policy. A policy can apply to an upstream set or a single upstream of exchanges and/or queues. In this example we apply to all upstreams, federation-upstream-set is set to all. set up policy

    NOTE: Policies are matched every time an exchange or queue is created.

  3. Set up the federation to the upstream server.
    1. Open the RabbitMQ Management Interface on the downstream server and go to the 'Admin'->'Federation Upstreams' screen and press 'Add a new upstream'. Fill in all information needed, the URI should be the URI of the upstream server. Leave expiry time and TTL blank. Leaving this blank means that it will stay "forever".

      set up federation

    2. Set up the queues that should be federated.

      The queues can be created as always - manually from the management interface or from the application code. The queues should be marked as federated if the policy is applied, as shown in the image below. If the queues are not marked as federated, control that the regexp is working.

      federated queues

  4. Move consumers and publishers

    Everything is now set up and it is time to move publishers and/or consumers to the new cluster. Publishers and/or consumers can be moved in any order. The federated queue will only retrieve messages when it has run out of messages locally, when it has consumers that need messages, or when the upstream queue has "spare" messages that are not being consumed.

  5. Verify that messages published to the upstream server are consumed by the downstream server when consumers are moved to the downstream server.

Read more about cluster migration in our blog post: Cluster migration with RabbitMQ Queue Federation.