We are pleased to announce for our service offering, IBM Messages for RabbitMQ, the Preferred status for RabbitMQ 3.8.
RabbitMQ 3.8 brings with it a bevy of new features, including the most noteworthy—the introduction of quorum queues. This new queue type is a replicated queue based on the Raft consensus algorithm. The quorum queue is RabbitMQ’s strategic queue type for high availability and data safety and is aimed to replace classic mirrored queues. With quorum queues, the RabbitMQ community is looking to overcome synchronization issues of classic mirrored queues. For instance, queue synchronization problems are nonexistent since a quorum queue can only confirm the reception of a message if the majority of replicas have written it to disk.
We highly recommend that you leverage quorum queues in favor of classic mirrored queues when using the IBM Messages for RabbitMQ service.
Changes to service
As part of delivering the best RabbitMQ experience possible, we are making some changes to our service to improve resiliency and flexibility:
- For a message delivery with guaranteed durability and consistent quality of service, customers must use quorum queues. As recommended by the RabbitMQ community, any workload using transactions or classic mirrored queues should switch to quorum queues. In many cases, this can be done with a minor code change when configuring a queue.
- Usage of classic queues:
- To support higher-throughput “transient” workloads, customers are free to continue using classic transient queues. By default, these queues will be mirrored across three nodes, but messages are not written to disk. However, these queues are aimed for transient workloads, and we will favor availability over consistency for this queue type. Any queue found in an “undefined” (or leaderless) state will be automatically deleted and cannot be recovered. It is the responsibility of the customer to recreate such a queue.
- Given the reduced feature set of quorum queues, we will allow the usage of classic mirrored durable queues, but with certain disclaimers. Nevertheless, because of the known RabbitMQ limitations, we highly encourage customers to avoid using classic mirrored queues. In contrast to previous RabbitMQ versions, our focus for classic mirrored queues will be on service availability over data consistency. As a result, when synchronization issues occur with classic mirrored queues, data may be lost—the system prioritizes availability over consistency. Like with transient queues, any classic mirrored queue found in an “undefined” (or leaderless state) will be automatically deleted and cannot be recovered. It is the responsibility of the customer to recreate such a queue.
- With RabbitMQ 3.8, we will change the network partition handling strategy from “pause-minority” to “autoheal.” In addition, we will change the ha-promote-on-shutdown policy key from “when-synced” to “always.” These changes take effect on the service-availability over data-consistency approach for classic mirrored queues as described above. For details, see the RabbitMQ documentation.
Given that Messages for RabbitMQ 3.7 is End of Life on IBM Cloud in September 2020, please check out how to upgrade right away.