Skip to main content
Version: Latest

Rolling Back RabbitMQ to earlier version in a9s Messaging

caution

This guide describes an emergency rollback procedure for a9s Messaging 4 to manually switch to legacy templates. This procedure should only be used in emergency cases and as a method of last resort.

RabbitMQ 4 minor updates can introduce client-side breaking changes. Because of the vendor's release policy, it is not feasible for anynines to release these versions as major versions of the a9s Messaging Data Service.

Therefore, these minor versions are released as in-place minor version updates for a9s Messaging 4. Relevant information about breaking changes at future a9s Messaging 4 in-place updates are announced in the CHANGELOG.md and the UPGRADE.md file of the corresponding anynines-deployment release.

Customers must check their client applications and update them accordingly. If the clients cannot be updated in time, it is also possible to block the in-place update for a9s Messaging as described in Safely Evaluating RabbitMQ 4.x Minor Updates.

In the case where the latest a9s Messaging 4 version has been introduced and problems are discovered at a later date, this guide provides an emergency procedure to manually roll-back to templates that offer the previous RabbitMQ minor release.

Example Scenario

The latest a9s Messaging 4 versions uses RabbitMQ 4.2. If problems are detected, this guide can be used to manually roll back to legacy templates that use RabbitMQ 4.1.

Emergency Rollback to Legacy Version

To use the legacy template, the corresponding BOSH release (hardcoded in the legacy template) must be uploaded to the BOSH director manually, in case it does not exist anymore.

Required Steps to Use the Legacy Template​

Prerequisites​

  • Extend the Service Broker catalog by adding a new legacy plan using the legacy template (e.g. messaging41-replica-ssl). For more information, see Service Catalog.
  • Redeploy the a9s Service Broker with the updated catalog by running bosh -d <DEPLOYMENT_NAME> deploy.
  • Update the a9s Service Broker by running cf update-service-broker <BROKER> <USERNAME> <PASSWORD> <URL>.
  • Enable Service Plan for the dedicated CF org(s) and space(s) by running cf enable-service-access <SERVICE> -b <BROKER> -p <LEGACY_PLAN_NAME> -o <ORG_NAME>.
  • Provision a new Service Instance with the legacy plan by running cf create-service <SERVICE> <LEGACY_PLAN_NAME> <NEW_INSTANCE_NAME>.
  • Migrate the data manually from the current Service Instance to the legacy Service Instance. For detailed steps, see Migrating Data Between a9s Messaging Service Instances.
  • Rebind the application to the legacy Service Instance.
  • Update the application to satisfy the requirements of the latest version.
  • Either migrate data back to the original Service Instance (queues, messages, bindings) or perform an in-place cf update-service to move this Service Instance to the newer plan. You need to configure the migration_path of the corresponding service plans accordingly.

Alternative Approach - Attempt an In-Place Downgrade​

caution

This option can be faster than provisioning a fresh Service Instance, but it is highly dependent on the current RabbitMQ version and template combination and may fail. Proceed only if you can revert to the recommended approach without data loss.

  • Configure the migration_path of the corresponding service plans accordingly.
  • Downgrade the existing Service Instance in place: cf update-service <INSTANCE_NAME> -p <LEGACY_PLAN_NAME>.
  • Adjust the application so that it meets the new version's requirements.
  • After the application is stable, switch the Service Instance back to the latest plan: cf update-service <INSTANCE_NAME> -p <LATEST_PLAN_NAME>.

If any step fails, revert to the recommended migration-based approach.