Converting between shared and dedicated clusters for instances - ApsaraMQ for RabbitMQ

Shared and dedicated instances

ApsaraMQ for RabbitMQ offers the following instance deployment architectures for each series:

Series	Shared instances	Dedicated instances
Subscription series	Professional Edition, Enterprise Edition	Platinum Edition
Serverless series	Shared	Dedicated

Instances from different series cannot be converted. However, instances within the same series support smooth upgrade or downgrade between specifications.
Older subscription instances might encounter errors during upgrade or downgrade. If you cannot perform an upgrade or downgrade, submit a ticket for assistance.
Only running instances can be upgraded or downgraded.
Shared instances do not support directly changing the authentication method or upgrading to Dedicated or Serverless editions that use open-source identity authentication. If you need to use open-source identity authentication, purchase a new Dedicated or Serverless instance. Create the new instance and verify your business before releasing the old instance.
Cross-architecture conversions support only specification upgrades or downgrades within the same series. Direct conversions across series or across authentication systems are not supported.

Instance conversion involves the following types of migration:

Upgrade

When an instance migrates from a shared cluster to a dedicated cluster, a new cluster is created and becomes the destination cluster for migration.
Downgrade

When an instance migrates from a dedicated cluster to a shared cluster, the shared cluster directly serves as the destination cluster for migration.

Dual-write and dual-read phase: Read and write routing is established on the destination cluster. Both clusters are readable and writable.
Single-write and dual-read phase: The source cluster no longer accepts writes but remains readable. The destination cluster is readable and writable.
Wait for source cluster consumption completion phase: The system waits for all messages in the source cluster to be consumed. If the source cluster has accumulated unconsumed messages or unexpired scheduled messages, this phase takes longer.
Destination cluster single-write and single-read phase: After all messages in the source cluster are consumed, the source cluster stops accepting reads and writes. All traffic is routed to the destination cluster, and the migration completes.

VPC access point/Public network access point
- Shared cluster migration to dedicated cluster
  
  The server does not actively migrate connections. After migration begins, new connections go directly to the destination cluster, but existing connections on the source cluster remain active. To ensure all connections use the new cluster, restart your application to reconnect.
- Dedicated cluster migration back to shared cluster
  
  Because the dedicated cluster must be decommissioned, the server actively disconnects existing connections on the source cluster. If the client supports automatic reconnection, it reconnects to the destination cluster automatically.
PrivateLink endpoint

All connections using PrivateLink endpoints experience disconnections lasting several minutes during instance migration.

When a dedicated cluster migrates back to a shared cluster, connections are actively disconnected. Perform migrations during off-peak hours and ensure your client has a robust reconnection mechanism. For details, see Configure automatic client reconnection.
For VPC or public network access point connections, existing connections migrate to the destination cluster only after the application or server restarts (for example, during a source cluster upgrade). Source cluster upgrades or similar actions may cause unexpected connection disconnections. To fully switch to the destination cluster, restart your application during off-peak hours.
For PrivateLink endpoint connections, disconnections lasting several minutes occur during migration. Perform migrations during off-peak hours and ensure your client has a robust reconnection mechanism.
If the source cluster has accumulated unconsumed messages or unexpired scheduled messages, the storage migration phase takes longer.

What should I consider when upgrading a RabbitMQ instance from Professional Edition to Enterprise Edition?

Entry point: Check whether the Upgrade button is available in the upper-right corner of the instance console. If the button is present, the instance supports upgrade operations.
Timing: Perform the upgrade during off-peak hours.
Connection stability: Upgrades generally do not cause disconnections. However, implement automatic reconnection logic in your application code as an additional safeguard. For more information about reconnection configuration, see Automatic Reconnection.
Configuration retention: The upgrade only increases resource limits. Existing configurations such as Queues, Vhosts, and other metadata remain unchanged, and the access endpoint does not change.