To enhance the reliability and fault tolerance of the RabbitMQ message queue cluster, users are offered the option to enable the Default Image Queue when they create a RabbitMQ cluster or a Vhost, provided the cluster has at least three nodes. This image queue can duplicate messages across multiple nodes within the RabbitMQ cluster, ensuring that messages in the queue are not lost in the event of a node failure.
Below is a detailed description of the default image queue policy parameters provided by RabbitMQ for users:
Parameter Name
Configuration Parameters
Parameter Description
Name
pay-mirror-policy
Policy name, used to identify and reference the policy.
Pattern
.*
The match mode of the policy, which uses regular expression syntax. The dot (.) indicates matching any character, and asterisk () indicates matching the preceding character zero or more times, so . indicates a queue that matches any name.
Apply to
Queues
The application object of the policy, set to Queues to indicate that the policy applies to queues.
Priority
0
The priority of the policy. If a queue matches multiple policies, then the policy with the highest priority will be applied. 0 indicates the lowest priority.
ha-mode
exactly
The copy mode of the image queues.
exactly: The messages of the queue will be copied to a specified number of nodes
all: The messages of the queue will be copied to all nodes.
Choosing exactly allows for reduced network and storage overhead while ensuring availability, thus improving performance.
ha-params
3
The copy parameters of image queues. When ha-mode is set to exactly, the number of copied nodes must be specified here. The default setting is 3, which can still maintain a good performance level even if expanded to 5 nodes in the future.
ha-promote-on-failure
always
The promotion policy for image queues in the event of a node failure. always means that regardless of the cause of the node failure, the image queue will be promoted to the main queue. when-synced means that the image queue will only be promoted to the main queue once it has resynchronized after the node failure. The default setting is always, to ensure service availability under any failure conditions.
ha-promote-on-shutdown
when-synced
The promotion policy for image queues when a node is shut down normally.
always: Regardless of the reason for the node shutdown, the image queue will be promoted to the main queue.
when-synced: The image queue will only be promoted to the main queue once it has resynchronized after the node shutdown.
The default setting is when-synced, to avoid unnecessary promotion operations.
ha-sync-mode
manual
Synchronization mode of image queues.
automatic: Indicates that the image queue will automatically sync with the main queue when a node is enabled or reconnected to the cluster.
manual: Indicates that the synchronization operation needs to be manually triggered to sync the image queue with the main queue.
The default setting is manual, to avoid auto-sync impacting cluster performance during message heap.
By configuring the default image queue policy, it is possible to optimize performance and resource utilization while ensuring the reliability of the RabbitMQ cluster. Users can further adjust these parameters according to their own requirements and scenario, or delete and create a new policy.
Directions
Enabling Default Image Queue
1. To enable image queues when you create a cluster: Purchase page for cluster > Other Configurations > Enable Mirrored Queue.
2.
3. To enable image queues when you create a Vhost: Cluster List> Vhost > Create Vhost > Enable Image Queue.
Limit
RabbitMQ Message Queue only allows clusters with three or more nodes to enable the Default Image Queue, mainly to ensure the high availability and fault tolerance of the cluster. In a cluster with three or more nodes, image queues can copy messages across multiple nodes. This not only shares the load across each node, improving performance, but also ensures the normal operation of the service in case of a node failure. At the same time, it provides greater flexibility, allowing us to configure image queue parameters according to actual needs. Therefore, this limit is in place to provide a more stable and reliable service.
Yes
No
Was this page helpful?