Всем привет! У нас кластер RMQ из 3-х нод в кубернетес,

4000 quorum single-active-user очередей, у 3000 expire по 60 сек. и после они пересоздаются, клиентами являются Node.js приложения с библиотекой amqplib

Когда перевалили за 2500 очередей при любой проблеме кластера (отвалилась на пару минут сеть, проблемы репликации, проблемы смены лидера, etc.) RMQ просто рассыпается:

– Очереди и кастомные exchange продолжают жить, в них можно писать, можно читать, но при этом фактически ничего не записывается и не читается
– Рандомно начинает закрывать коннекты (541 ошибка, вроде)
– Акаем сообщение, но он этого не видит и пересылает сообщение заново
– Может прийти ECONRESET при этом соединение не закрывается, но библиотека продолжает пытаться отправить heartbeat в мертвый сокет (но тут, конечно, больше проблемы самой либы и это более менее попровили)

Ресурсов точно хватает

Единственные способы лечения: удалять очередь / exchange, перезагружать ноды, а иногда просто приходилось открывать новый кластер и перепрыгивать на него

Мы никак не можем понять в чем проблема, есть ли здесь кто-то, кто может помочь / сделать платную аналитику и консультацию?

Честно говоря не припоминаю на слуху подобные кейсы использования реббита. Не хватает для понимания следующих вопросов - пробовали ли некворумные, классические очереди? - сколько unacked, ready сообщений висит в кластере? - какой мпс в чнн? - версия реббита Раз ваши проблемы решаются удалением очередей - а вам вообще нужен кластер/кворум?

1. С классическими очередями все ещё хуже, потому что в случае отвала сети внутри кластера он потом не может собрать что к чему 2. Пару сотен 3. 3-4 сообщений в минуту на большинство очередей 4. v3.10.7 Ещё уточню: single active consumer, все-таки только на тех 3000 очередях, а не на всех Я правильно понимаю, что наибольшее число вопросов возникает к факту удаления очередей?

Какие настройки репликации были у классических очередей? Вопросы скорее - зачем вам кворум/кластер если вы всё смело удаляете? Вообще надо смотреть логи. Также хотелось бы понять как вы подняли реббит-кластер - сами или поганым битнамишным оператором?

. "Настройки репликации"? Имете ввиду настройки персистенции? Если так, то пробовали как auto-delete (кластер в момент рассыпается), none (более менее, но при перезагрузке ноды тоже может рассыпаться) и durable (самый удобный вариант, но при проблемах в кластере работа с этими очередями просто останавливается) . кворум/кластер – нужно чтобы не важно есть или нет проблемы в моменте времени все сообщения обязательно дошли и дошли в правильной последовательности (а удаляем мы в случае, когда происходит условно "ребалансировка" очередей к приложениям) . Про операторы уточню у DevOps, а просто битмашиные операторы – а можно где-то почитать что с ними не так? Просто даже если не RMQ, то что-то на битнами операторах может быть у нас поднято

нет, именно настройки сборки после краха - попробовать автомат, меньше гарантий но и меньше гемора после развалов. я бы попробовал для начала собрать реббит кластер без битнами оператора, ручками и сравнить результат

{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}