Migrate between plans Upgrade or downgrade instance plan

Cluster migration can be done in different ways depending on requirements and plans.

Migrate between shared instances (Little Lemur and Tough Tiger)

It is possible to upgrade/downgrade automatically and seamlessly between shared plans. Go to the CloudAMQP control panel and press Edit and change plan type.

Migrate between dedicated instances

If you want to rescale your cluster, go to the CloudAMQP Control Panel, and choose edit for the instance you want to reconfigure. Here you have the ability to add or remove nodes, and change plan all together.

Migrate from shared to dedicated instances

There is no automatic upgrade/downgrade between a shared and a dedicated plans.

When moving to or from a dedicated instance to a shared instance we recommend queue federation for seamless migration, as described in section below.

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

  1. Create the new plan
  2. Point your publishers to the new plan
  3. Let your consumers empty the queues on the old instance
  4. Move your consumers over to the new instance
  5. Finish up by deleteing the old instance

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.

Queue federation connects an upstream queue and transfers messages to the downstream queue when there's consumers that has capacity on the downstream queue. Consumers and publishers can be moved in any order. Messages are transfered to the new cluster when your consumers are there. The federated queue will only retrieve messages when it has run out of messages locally, when it has consumers that need messages and when the upstream queue has "spare" messages that are not being consumed. Upstream servers are the servers towards messages are originally published. Downstream servers are where the messages get forwarded to.

  1. Start by setting up the new instance (the downstream server)
  2. Create a policy that matches the queues that you would like to federate

    A policy is a pattern that queue names are matched against. The "pattern" argument is a regular expression used to match queue (or exchange) names. Example: We can 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 management interface for 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.

    2. Leave expiry time and TTL blank. Leaving this blank means that it will stay "forever".

      set up federation

    3. Set up the queues that should be federated.

      The queues can be created as you always create your queues (i.e manually from the management interface or from the application code). The queues should be marked as federated if the policy is applied, like in the image below. If the queues are not marked as federated, control that the regexp is working.

      federated queues

  4. Everything is now set up. It is time to move the publisher OR the consumer to the new cluster. You can move the publisher and/or the consumer 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 the messages published to the upstream server are consumed by the downstream server when the consumers are moved to the downstream server.

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