ApsaraMQ for RabbitMQ lets you convert an instance between a shared and a dedicated cluster by changing its deployment architecture during an upgrade or downgrade. This topic describes the conditions and potential impacts of this conversion.
Shared and dedicated instances
The deployment architectures for different series of ApsaraMQ for RabbitMQ instances are as follows:
Series | Shared instance | Dedicated instance |
Subscription series | Professional Edition, Enterprise Edition | Platinum Edition |
Serverless series | Shared | Dedicated |
Conditions
You cannot convert instances between different series. You can upgrade or downgrade instances to different specifications only within the same series.
Errors may occur when you upgrade some older Professional Edition instances. If an upgrade fails, submit a ticket for assistance.
You can upgrade or downgrade an instance only when it is in the "In Service" state.
Migration process
The instance conversion involves the migration of the following components:
Cluster migration
Upgrade
When you upgrade an instance from a shared cluster to a dedicated cluster, a new cluster is created to serve as the target for the migration.
Downgrade
When you downgrade an instance from a dedicated cluster to a shared cluster, an existing shared cluster is used as the target for the migration.
Storage migration
Dual-write and dual-read phase: Read and write routing is established on the target cluster. During this phase, you can read from and write to both the source and target clusters.
Single-write and dual-read phase: Writes to the source cluster are stopped, but reads are still allowed. During this phase, you can read from the source cluster and read from and write to the target cluster.
Waiting for consumption on the source cluster to complete: The system waits for all messages on the source cluster to be consumed. If the source cluster has backlogged messages or unexpired scheduled messages, this phase may take a long time.
Target cluster single-write and single-read phase: After all messages on the source cluster are consumed, read and write operations on the source cluster are stopped. All message sending and consumption are routed to the target cluster. The migration is complete.
Connection migration
VPC endpoints/Internet endpoints
Migrating from a shared cluster to a dedicated cluster
The service does not proactively migrate connections. After the instance migration begins, all new connections are established with the target cluster. However, the service does not disconnect existing connections on the source cluster. To move all connections to the new cluster, you must restart your application to force a reconnection.
Migrating from a dedicated cluster back to a shared cluster
Because the dedicated cluster needs to be reclaimed, the service proactively disconnects existing connections on the source cluster. If the client is configured for automatic reconnection, it will reconnect to the target cluster, completing the connection migration.
PrivateLink endpoints
All connections that use PrivateLink endpoints will experience a disconnection that lasts for several minutes during the instance migration.
Impacts of migration
When you downgrade an instance from a dedicated cluster to a shared cluster, existing connections are proactively disconnected. We recommend that you perform this migration during off-peak hours and ensure that your client has a reconnection mechanism. For more information, see Configure automatic reconnection for a client.
When you upgrade from a shared cluster to a dedicated cluster, existing connections that use VPC or Internet endpoints are not proactively migrated. These connections remain on the source cluster. An event such as an application restart or a service upgrade on the source cluster can cause these connections to disconnect and then reconnect to the new target cluster. To ensure a smooth transition, we recommend that you restart your application during off-peak hours to migrate all connections.
For connections that use PrivateLink endpoints, the connections are disconnected for several minutes during the instance migration. We recommend that you perform the migration during off-peak hours and ensure that your client has a reconnection mechanism.
If the source cluster has backlogged messages or unexpired scheduled messages, the storage migration phase takes longer to complete.