Migrating between plans can be done in different ways depending on requirements and 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.
To scale a cluster, go to the
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.
The recommended process is to use rolling migration or queue federation for seamless migration, as described in the sections below.
If seamless migration is not required, create a new instance and move your clients:
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.
More details on the copy functionality in this blogpost.
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.
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.
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.
NOTE: Policies are matched every time an exchange or queue is created.
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".
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.
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.
Read more about cluster migration in our blog post: Cluster migration with RabbitMQ Queue Federation.