Replies: 2 comments 8 replies
-
|
Please don't just do what AI says. Almost everything there is incorrect. Somewhere in your broker logs there will be further information as to why at least 2 of the 3 members of the queue aren't running, perhaps they encountered an exception during recovery. You seem comfortable in running arbitrary commands in your environment so you could try:
This will retry the start phase of the queue member on node |
Beta Was this translation helpful? Give feedback.
-
|
With 1600 queues this can be a known scenario addressed by #14401, which will ship in |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
After a Kubernetes Upgrade (which merely cycles the RabbitMQ pods), two of ~2200 Queues (~1600 of then being Quorum Queues) were "broken".
RabbitMQ is in a 3 node cluster, RabbitMQ v4.1.4, using the RabbitMQ Operator.
I have now deleted the queue, to avoid crashlooping the client, but I tried to collect as much information as I could below.
Reproduction steps
I have no idea on how to reproduce this. We have not restarted RabbitMQ since the problem occured to keep things stable.
Expected behavior
The Queue Should not be unuseable.
Additional context
I tried to analyze what was going on in the background, however I'm quite lost when it comes to the innards and Erlang.
Logs for RabbitMQ:
Client Logs (Spring Boot):
Config in
/var/lib/rabbitmq/mnesia/.../quorum/2F_TOS0TRQCNWSKCG1/config(only on node 1)I tried recovering the queue (with whatever the AI said...)
Beta Was this translation helpful? Give feedback.
All reactions