Migrate between plans

Migrating between CloudAMQP plans can be done in different ways depending on requirements and the current plan.

Change between shared plans

Go to the CloudAMQP Console and click Edit to change the plan seamlessly. This will not lead to any changes in connection details, and there will be no downtime. The things that will change are the price, the max number of queues, the number of messages per month, the number of connections, and the maximum number of messages in queues.

Change between dedicated plans

To scale a cluster, go to the CloudAMQP Console and click Edit Follow the steps to change the plan and/or the number of nodes. You can add or remove nodes and change the plan at the same time.

Plan changes are a routine, fully automated operation that we run continuously across our fleet. Here's what happens when you make one.

How it works

Rather than resizing your servers underneath you, we provision a new server on the target plan for every node that needs new hardware, copy your data across while the current node carries on serving traffic, and then move the node over. Each new server takes over the hostname and IP address of the one it replaces, so your connection details stay the same.

The previous server stays running until its replacement is up and verified, so there's always a known-good state to return to. On a multi-node cluster we move one node at a time, so the cluster keeps serving your applications from start to finish.

How we keep it safe

A plan change is checked before it starts and guarded while it runs:

• We confirm the cluster is healthy and that your data comfortably fits the plan you're moving to before we begin.
• Only one plan change or disk resize runs on an instance at a time.
• Before a node is moved, we wait for its queues to be in sync with the rest of the cluster and relocate quorum queue and stream replicas to the nodes that are staying. If the timing isn't right, we pause rather than proceed.
• Nodes are drained gracefully, giving clients time to reconnect elsewhere.
• Individual steps are retried automatically, and our engineers are notified with full context if one needs attention.

If a pre-flight check pauses your plan change, the console explains why. Contact support@cloudamqp.com if you'd like a hand.

Getting the best result

A few things on your side make the change as smooth as possible:

• Use durable queues and persistent messages. Nodes restart during a plan change, so persistence is what carries your messages across.
• Keep queues short and load low. How much data sits on a node determines how quickly the change completes.
• Check that your clients reconnect automatically. Connections are closed as each node is drained, and clients with standard retry logic handle this transparently.

What to expect

On a multi-node cluster your service stays available throughout. Nodes are moved one at a time, and the remaining nodes keep serving your applications. Clients connected to the node being moved are asked to reconnect, which is why automatic reconnection is worth confirming.

On a single-node cluster there's no second node to take over, so the change includes a brief, planned pause of a few minutes while the broker moves to its new server. Keeping queues short before you start keeps that pause to a minimum.

Change from shared to dedicated plan

LavinMQ: Direct migration via the console

For LavinMQ clusters, you can migrate directly from a shared plan to a single-node dedicated plan via the CloudAMQP Console by clicking Edit.

Important: Your cluster will receive a new hostname after the migration. Make sure to update your connection strings before reconnecting.

Additional notes:

• Migration targets single-node dedicated plans only. You can expand to a multi-node cluster afterwards if needed.
• All broker definitions and data are preserved during the migration.

RabbitMQ: Rolling migration or queue federation

For RabbitMQ clusters, the recommended process is to use rolling migration or queue federation for seamless migration, as described 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 configuration 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 configurations 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. A queue federation or shovel can be used to move messages.

More details on the copy functionality can be found in our blog post: Copy your CloudAMQP configurations from one dedicated instance to another

Seamless migration with RabbitMQ queue federation

The RabbitMQ Federation plugin is used when migrating to another cluster without stopping all producers and consumers. 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 consumers 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.

Consumers and publishers can be moved in any order. Messages are transferred to downstream queues when consumers are there. The messages will be moved downstream when:

• Downstream Queue has run out of messages
• Downstream Queue has consumers who need messages
• Upstream Queue has "spare" messages that are not being consumed and/or when the upstream queue has "spare" messages that are not being consumed.

How to move messages with Queue Federation

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.

   In the RabbitMQ Management Interface: Navigate to Admin -> Policies and click 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

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

3. Set up the federation to the upstream server.

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

4. Set up the queues that should be federated.

   The queues can be created as always, manually from the management interface or 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, make sure that the regexp is working.

   

5. Move consumers and publishers

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

6. Verify that the downstream works as intended

   Verify that messages published to the upstream server are consumed by the downstream server once consumers have moved to the downstream server.

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