ApsaraMQ for RabbitMQ lets you change the deployment architecture of instances during upgrade or downgrade operations, enabling conversion between shared and dedicated clusters. This topic describes the conditions and potential impacts of such operations.
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 |
Conditions
Instances from different series do not support conversion. However, different specifications within the same instance series support smooth upgrade or downgrade.
Older subscription instances might encounter errors during upgrade or downgrade. If you cannot perform an upgrade or downgrade, submit a ticket for assistance.
Only instances that are in service can undergo upgrade or downgrade operations.
Migration procedure
Instance conversion involves the following types of migration:
Cluster 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.
Storage migration
Dual-write and dual-read phase: Read/write routing is established on the destination cluster. Both the source and destination 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 the source cluster to finish consuming messages. If the source cluster has stacked messages awaiting consumption or unscheduled messages that have not expired, this phase will take longer.
Destination cluster single-write and single-read phase: After all messages in the source cluster are consumed, the source cluster no longer accepts reads or writes. All sends and consumes are routed through the destination cluster, and the migration completes.
Connection migration
VPC access point/Public network access point
Shared cluster migration to dedicated cluster
The server-side does not actively migrate connections. After instance migration begins, all new connections connect directly to the destination cluster. However, the server-side does not actively disconnect existing connections (those already established on the source cluster before migration). 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 revoked, the server-side actively disconnects existing connections on the source cluster. If the client is configured for automatic reconnection, it will reconnect to the destination cluster, completing the connection migration.
PrivateLink endpoint
All connections using PrivateLink endpoints experience disconnections lasting several minutes during instance migration.
Migration impacts
When a dedicated cluster migrates back to a shared cluster, connections are actively disconnected. Perform migrations during off-peak hours and ensure a robust reconnection mechanism. For reconnection configuration, see Configure automatic client reconnection.
For connections using VPC access points or public network access points, when a shared cluster migrates to a dedicated cluster, existing connections migrate and reconnect to the destination cluster only after the application or server-side restarts (such as 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 to complete the reconnection.
For connections using PrivateLink endpoints, disconnections lasting several minutes occur during instance migration. Perform migrations during off-peak hours and ensure a robust reconnection mechanism.
If the source cluster contains stacked messages awaiting consumption or unscheduled messages that have not expired, the storage migration phase will take longer.