Сделайте RabbitMQ долговечными / постоянными очередями, чтобы выжить после перезапуска Kubernetes pod

Наше приложение использует RabbitMQ только с одним узлом. Он запускается в одном модуле Kubernetes.

Мы используем устойчивые / постоянные очереди, но каждый раз, когда наш облачный экземпляр отключается и восстанавливается, а модуль RabbitMQ перезапускается, наши существующие устойчивые / постоянные очереди исчезают.

Сначала я подумал, что проблема в том, что объем, на котором хранились очереди, не был постоянным, но оказалось, что это не так.

Похоже, что данные очереди хранятся в /var/lib/rabbitmq/mnesia/<user@hostname>. Поскольку имя хоста модуля меняется каждый раз, он создает новый набор данных для нового имени хоста и теряет доступ к ранее сохраненной очереди. У меня есть много наборов файлов, созданных в папке mnesia, все из предыдущих перезапусков.

Как я могу предотвратить такое поведение?

Ближайший ответ, который я смог найти, находится в этом вопросе, но если я правильно его прочитал, это будет работать, только если у вас есть несколько узлов в кластере одновременно, совместно использующие данные очереди. Я не уверен, что это сработает с одним узлом. Или нет?


kubernetes rabbitmq persistence persistent-storage
person JoeMjr2    schedule 21.06.2019    source источник
comment
Особые настройки RabittMQ: Долговечность Долговечные очереди сохраняются на диске и, таким образом, выживают брокер перезагружается. Очереди, которые недолговечны, называются временными. Долговечность очереди не делает сообщения, которые направляются в эту очередь, долговечными. Если брокер отключен, а затем восстановлен, постоянная очередь будет повторно объявлена ​​ во время запуска брокера, однако будут восстановлены только постоянные сообщения. Это делается через свойство сообщения (delivery_mode или, в некоторых клиентах, постоянное).   -  person Mark    schedule 26.06.2019
comment
@ JoeMjr2 Удалось ли вам решить эту проблему? :)   -  person ParthS007    schedule 01.06.2021

Ответы (3)


arrow_upward
0
arrow_downward

Как я могу предотвратить такое поведение?

Используя StatefulSet, предназначенный для случая, когда модули имеют постоянные данные что связано с их «идентичностью». Таблица Helm - отличное место для начала чтения, даже если вы в конечном итоге не воспользуетесь им.

person mdaniel    schedule 22.06.2019
comment
Это, вероятно, лучшее решение, но было бы полезно предоставить более подробную информацию о том, как добиться этого с помощью этих методов. - person Rob G; 27.11.2019

arrow_upward
0
arrow_downward

Я сам столкнулся с этой проблемой, и самый быстрый способ, который я нашел, - это указать переменную среды RABBITMQ_NODENAME = "yourapplicationsqueuename" и убедиться, что у меня есть только одна реплика для моего модуля.

person Rob G    schedule 26.11.2019

arrow_upward
0
arrow_downward

В нашем случае помогло установить hostname: <static-host-value>

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 1
  ...
  template:
    metadata:
      labels:
        app: rabbitmq
    spec:
      ...
      containers:
      - name: rabbitmq
        image: rabbitmq:3-management
        ...
      hostname: rmq-host
person merrycoder    schedule 10.05.2021
comment
где вы добавили hostname? - person ParthS007; 01.06.2021
comment
я обновил ответ @ ParthS007 - person merrycoder; 28.06.2021