mirror_queue_slave memory

[kingsunc]

Describe the bug

Reproduction steps

install:

erlang-23.3.4.7-1.el7.x86_64.rpm

rabbitmq-server-3.10.7-1.el8.noarch.rpm

Expected behavior

1. A、B、C node in IDC jinan，D、E、F node in IDC beijing
2. A、B、C、D、E、F，when all node send and recv , the memory of mirror_queue_slave in federation is continuously rising。

Additional context

No response

[mkuratczyk]

Queue mirroring has been deprecated for a long time and will be removed soon. Issues like this one are among the reasons we invested into developing far superior quorum queues.

For a quick but not guaranteed fix, you can try to upgrade:

1. We reduced slave memory usage in same cases: Dead lettering en masse can overload the DLQ #5312
2. In 3.12, especially with classic queues v2, the efficiency improvements may give you better results

Please test this in a test environment first though. What you are seeing is caused by a queue master overloading a slave. Performance improvements in 3.11/3.12 and classic queues v2 may lead to situations where the slaves are overloaded even faster (but in some other cases will lead to them not being overloaded at all)

Migration to quorum queues is the real answer.

[kingsunc]

Normal queue set quorum so easy, but the federation queue how to set quorum?

[kingsunc]

Quorum cannot completely replace mirroring, because node downtime, the mirror is available, but quorum is not available.

[mkuratczyk]

Yes, a quorum queue requires a quorum (majority) of nodes to be up. That's by design according to the RAFT algorithm. It is a difference, but it doesn't change the fact that queue mirroring will be removed.

[kingsunc]

Now update to 3.12.0, the question is solved, thanks！

[michaelklishin]

#3925, #2973 are also highly relevant.

At the very least please upgrade to 3.11.18 and then 3.12.0 or 3.12.1 (expected to ship this week).

[kingsunc]

Now update to 3.12.0, the question is solved, thanks！