All Products
Search
Document Center

Migration Hub:Migrate a self-managed RabbitMQ cluster to a self-managed RabbitMQ cluster on Alibaba Cloud

Last Updated:Nov 24, 2025

1. Scenarios

This solution applies to the migration of a self-built RabbitMQ cluster from other cloud platforms or an Internet data center (IDC) to a self-built RabbitMQ cluster on Alibaba Cloud ECS. This migration focuses on metadata, such as the configuration for queues, exchanges, bindings, and user permissions, but does not include message content.

2. Migration tools

1. Built-in open source RabbitMQ migration tools

RabbitMQ provides the following core tools for metadata migration:

  • rabbitmqctl: Manages RabbitMQ nodes. It supports exporting and importing configurations, such as queues, exchanges, and user permissions.

  • rabbitmqadmin: A command line interface (CLI) based on the HTTP API that supports managing RabbitMQ metadata through REST interfaces.

3. Migration plan

1. Overall migration process

  • Instance creation:

    • Deploy a RabbitMQ cluster on Alibaba Cloud ECS. Ensure the version is compatible with the source environment.

    • Configure network policies, such as security groups and Virtual Private Cloud (VPC), to ensure secure communication between the source and destination instances.

  • Data migration:

    • Metadata migration: Use rabbitmqctl or rabbitmqadmin to export metadata from the source RabbitMQ instance and import it to the destination instance.

    • Configuration synchronization: Synchronize user permissions, virtual host (vhost) configurations, and the status of enabled plugins.

  • Data validation: Verify that the metadata on the destination instance is consistent with the source instance. Ensure that configurations for queues, exchanges, and binding relationships are correct.

2. Data migration plan

2.1. Migrate metadata using built-in open source RabbitMQ migration tools

Migration principle:
Prerequisites:
  • The versions of the source and destination RabbitMQ instances must be compatible. Using the same version is recommended.

  • Ensure that the source and destination instances can access each other over the network.

  • Install and enable the necessary plugins on the destination instance, such as rabbitmq_management.

Risks and notes:
  • Version difference risk: Different versions of RabbitMQ may have different configuration formats. Verify compatibility in advance.

  • Permission issues: Ensure that the user performing the migration has configure and write permissions.

  • Data overwrite risk: Existing configurations on the destination instance might be overwritten. Back up the configurations beforehand.

  • Network stability: Maintain a stable network during the migration to avoid interruptions that could lead to configuration inconsistencies.

3. Data validation plan

  • Metadata comparison

    • Use commands such as rabbitmqctl list_queues, rabbitmqctl list_exchanges, and rabbitmqctl list_bindings to compare the queues, exchanges, and binding relationships between the source and destination instances.

    • Query the metadata in JSON format using rabbitmqadmin and perform an item-by-item comparison.

  • Permission verification

    • Verify that the user permissions on the destination instance, such as vhost access permissions and operation permissions, are consistent with the source instance.

  • Logs and monitoring

    • Check the logs of the destination instance (/var/log/rabbitmq/*.log) to confirm that the migration completed without exceptions.

    • Use Alibaba Cloud monitoring tools, such as Cloud Monitor, to monitor the operational status of the destination instance.

4. Migration implementation process

1. Migrate metadata using built-in open source RabbitMQ migration tools

1.1. Export metadata from the source instance

On the source RabbitMQ instance, run:

rabbitmqctl export /path/to/export.json

Or, export using rabbitmqadmin:

curl -u guest:guest http://<source_ip>:15672/api/overview -o source_metadata.json

1.2. Import metadata to the destination instance

On the destination RabbitMQ instance, run:

rabbitmqctl import /path/to/export.json

Or, import using rabbitmqadmin:

curl -u guest:guest -X POST -H "Content-Type: application/json" --data @export.json http://<target_ip>:15672/api/import

5. Data validation process

1. Compare queue and exchange configurations

Run the following commands on the source and destination instances respectively:

rabbitmqctl list_queues name
rabbitmqctl list_exchanges name type
rabbitmqctl list_bindings

Compare the outputs to ensure they are identical.

2. Verify user permissions

Run the following commands:

rabbitmqctl list_users
rabbitmqctl list_permissions -p <vhost>

Confirm that the user permissions, such as configure, write, and read, are consistent with the source instance.

3. Check logs and monitoring

  • Check the logs of the destination instance to confirm that there are no error or warning messages.

  • Use Alibaba Cloud Cloud Monitor to monitor metrics such as CPU, memory, and disk I/O to ensure service stability after the migration.

6. Migration notes

  • Network connectivity: Ensure network connectivity between the source and destination instances. Add security group rules as needed.

  • Version compatibility: The source and destination RabbitMQ versions must be compatible to prevent migration failures caused by differences in the configuration format.

  • Data consistency: Create a snapshot backup of the source instance before migration to prevent accidental data loss.

  • Permission management: Use a user with configure permissions for the migration to prevent failures caused by insufficient permissions.

  • Test environment verification: Before the official migration, simulate the migration process in a test environment to verify its feasibility.

  • Service downtime window: If your business cannot be interrupted, evaluate whether an online migration is supported, for example, using mirrored queues or a dual-write mechanism.

  • Monitoring and rollback: Continuously monitor the operational status of the destination instance after migration. If you find any issues, promptly roll back to the source instance.