Phenomenon of a node set as management (disk mode) being assigned as the master node of a queue during cluster configuration

[0Ams]

Describe the bug

I have configured a cluster with rabbitmq node1 (disk mode), node2 (ram mode), and node3 (ram mode), and used ha-mode for a specific queue. At this point, I added the setting "queue-master-locator":"min-masters" to allow the queue's master to be set.

Ultimately, I discovered a phenomenon where node1 (disk mode) is set as the master node of the queue. Here, I'm curious about two things:

In a clustering environment, if the ha-mode master of the queue is selected as node1 in disk mode, will there be any performance issues?
Is there a separate setting to prevent node1 (disk mode), which became the management node for setting up the clustering environment, from becoming the ha-mode master of the queue? For the second question, I found that it can be set to client-local, but I'm wondering if there's a simpler alternative.
Also, in a cluster environment, node1 must be set to disk mode for management, but it seems that setting node1 in disk mode as the master node of the queue's ha-mode could lower performance compared to when nodes2 and 3, which use ram mode, are selected. I'm curious about why it isn't excluded as a default option.

I'm looking forward to your assistance.

Reproduction steps

1. "rabbitmq node1" is management node & disk mode
2. "rabbitmq node2, 3" clustering by "-rabbit cluster_nodes {['rabbit@node'],ram}"
3. add queue policy "rabbitmqctl --node rabbit@node1 set_policy qml "test" '{"queue-master-locator":"min-master","ha-mode":"exactly","ha-params":3,"ha-sync-mode":"automatic"}' --priority 0;"
   ...
   queue1 master node is a node1 and mirror node is a node2,node3

Expected behavior

In a cluster environment using ha-mode, the management node operating in disk mode should be excluded from selection as the master node of the queue ha-mode.

Additional context

No response

[michaelklishin]

There is no such thing as a "management node" in RabbitMQ since 3.6.7 (shipped in 2016 or 2017 IIRC). All nodes collect their own stats, and all nodes that have the management plugin enabled can serve HTTP API requests. The recommended monitoring option is Prometheus and Grafana, or an alternative set of tools that use the Prometheus format.

Mirrored classic queues will be removed completely for RabbitMQ 4.0, in fact, the a pull request to remove them is close to being ready. Their doc guide has been flashing very visible warnings for years now). So will be RAM nodes are they are completely incompatible with Khepri.

See quorum queues (have been around since 2017-2018) and streams (have been around since 2021).