Running outdated broker versions exposes your messaging infrastructure to unpatched bugs and missed optimizations. ApsaraMQ for RocketMQ automatically updates your broker to the latest version during a configurable maintenance window, so your instances stay current without manual intervention. Message sending and receiving continue throughout the update.
Adjust the maintenance window and update schedule to align with your traffic patterns and minimize disruption.
Supported editions
Version management is available only for Enterprise Platinum Edition instances.
How it works
Version number format
ApsaraMQ for RocketMQ uses the format x.y-rmq-yyyymmdd:
| Segment | Meaning | Example |
|---|---|---|
x.y | Corresponds to the open-source Apache RocketMQ version x.y.z, where z is the latest patch | 5.1 maps to Apache RocketMQ 5.1.z |
yyyymmdd | ApsaraMQ for RocketMQ release date. Each release includes feature changes, optimizations, and bug fixes | 20230329 |
Update examples:
5.0-rmq-20230329to5.1-rmq-20230329-- open-source version bump5.0-rmq-20230329to5.0-rmq-20230411-- ApsaraMQ for RocketMQ patch update
For details about each release, see Release notes for ApsaraMQ for RocketMQ 5.x.
Update rules
| Property | Detail |
|---|---|
| Update method | Automatic. The system creates an update task when a new version is announced. |
| Target version | Always the latest available version, regardless of how many intermediate versions exist. |
| Version validity | Each version is supported for 6 months. |
| Rollback | Not supported. After an update completes, the instance cannot revert to a previous version. |
Update task scheduling
| Property | Detail |
|---|---|
| Scheduled time | The start of the nearest maintenance window on the release date |
| Deadline | Seven days after the scheduled time |
| Task generation | Immediately after the update announcement is released |
| Cancellable | No |
| Reschedulable | Yes |
Maintenance window
The maintenance window controls when automatic updates run.
Default window: 02:00 -- 06:00.
To customize the window, see Change the maintenance window.
A changed window applies only to update tasks created after the change. Existing pending tasks keep their original schedule.
If the start time and end time are identical, the update can run at any time that day.
If the end time is earlier than the start time, the window spans midnight. For example, start
11:00/ end02:00means the update can run between 11:00 on the current day and 02:00 on the next day.
Update impacts and preparation
Review these impacts and prepare your applications before an update runs.
Duration and connectivity
Most updates complete within 30 minutes. If an update exceeds this time, submit a ticket. Enterprise Platinum Edition users can also report issues in the DingTalk group.
Brokers restart in batches during the update. Clients may experience brief reconnections, but messages can still be sent and received.
Duplicate message delivery
Messages may be consumed more than once during the update. Make sure your consumers handle duplicates gracefully by implementing idempotent consumption. For guidance, see Message idempotence.
Restricted operations during updates
While the update is in progress, the following operations are blocked:
| Blocked operation | Available alternative |
|---|---|
| Unsubscribe from instance | Wait until the update completes. See Unsubscription process. |
| Release instance | Wait until the update completes. See Release an instance. |
| Downgrade or upgrade configurations | Wait until the update completes. See Modify instance configurations. |
| Create or delete topics and other resources | Avoid resource management operations in the console during the update. |
Note: Renewal remains available during updates. See Renew an instance.
No rollback after completion
After an update completes, the instance cannot revert to a previous version. Verify that your applications are compatible with the latest broker version before the scheduled update.
Prepare for updates
Follow these practices to minimize disruption during version updates:
Schedule updates during off-peak hours. Adjust the maintenance window to a period with low traffic to reduce the impact of transient reconnections.
Implement idempotent consumption. Because messages may be delivered more than once during an update, design consumers to handle duplicates. See Message idempotence.
Freeze resource changes during updates. Do not create, delete, or modify topics and other resources while an update is running.
Verify application compatibility. Test your applications against the new broker version before the scheduled update, since rollback is not supported.
Reschedule an update task
Change when a pending update task runs.
Log on to the ApsaraMQ for RocketMQ console. In the left-side navigation pane, click Instances.
In the top navigation bar, select a region, such as China (Hangzhou). On the Instances page, click the name of the instance that you want to manage.
On the Instance Details page, click the Version Management tab.
Click the Pending Tasks tab.
Find the update task and click Change Time in the Actions column.
In the Modify Pending Task Update Time panel, set the Newly Scheduled Update Time and click OK.
After rescheduling, confirm that the Pending Tasks tab shows the new execution time for the task.
Change the maintenance window
Customize the time range during which automatic updates run.
Note: The new window applies only to update tasks created after the change. Existing pending tasks keep their original schedule. To change the time of an existing task, see Reschedule an update task.
Log on to the ApsaraMQ for RocketMQ console. In the left-side navigation pane, click Instances.
In the top navigation bar, select a region, such as China (Hangzhou). On the Instances page, click the name of the instance that you want to manage.
On the Instance Details page, click the Version Management tab. In the upper-right corner, click Update Configuration.
In the Modify Version Update Configurations panel, set the new maintenance window and click OK.
After saving, return to the Version Management tab and confirm that the displayed maintenance window matches the values you configured.
Related topics
Release notes for ApsaraMQ for RocketMQ 5.x -- Review what changed in each broker version.
Message idempotence -- Implement idempotent consumption to handle duplicate messages during updates.
Renew an instance -- Extend instance validity, which remains available during updates.