У нас есть два кластера RabbitMQ.Один используется в качестве восходящего, а другой - в качестве нисходящего.Каждый кластер имеет 3 узла.Мы получаем сообщения, которые публикуются при обмене заказами в вышестоящем кластере и в нижестоящий кластер с использованием RabbtitMQ - Federation.
Это работало нормально с последних 6 месяцев.Внезапно 10/4 мы получили ошибку раздела кластера в восходящем кластере.Это произошло из-за того, что одна из систем кластера зависла более чем на минуту.Мы видели повторяющуюся информацию об этом в системных журналах и временно отключили эту систему.Восходящий кластер теперь работает как кластер из двух узлов.это не было замечено тогда, но 10/8 мы поняли, что на нисходящем узле мы не получаем никаких сообщений о заказе с 10/4.
После дальнейшего исследования я обнаружил, что ссылка федерации на нисходящем кластерепо-прежнему отображается как запущенный, но в автоматически созданной очереди «объединения» в вышестоящем кластере накоплено более 87 000 сообщений.Чтобы получить эти сообщения, я перезапустил ссылку федерации из нижестоящего кластера.Но неожиданно я увидел, что очередь «федерации» удалялась и воссоздалась на портале, перенося эти 87 000+ сообщений также во тьму космоса.С того времени мы начали получать новые сообщения, но старые сообщения были просто утеряны.
Прежде чем приступить к решению проблемы, мы выполнили некоторые действия для этого, отключив оба кластера один за другим.Каждый раз очередь федерации могла сохранять постоянные сообщения.И всякий раз, когда оба кластера находились в правильном состоянии, нисходящий канал федерации мог получать эти сообщения.Итак, мы пришли к выводу, что всякий раз, когда очередь «федерации» доступна на вышестоящем узле, «канал федерации» на нисходящей стороне должен выбирать сообщения;и, следовательно, мы никогда не ожидали этой проблемы.
Ни мы не устанавливаем параметры x-expire и x-message-ttl в конфигурации федерации, ни приложение не устанавливают их при публикации сообщений.Мы используем только «trust-user-id»: false, URI (все 3 узла кластера) и имя обмена в конфигурации федерации.Rest all по умолчанию, что означает, что «x-expire» в очереди федерации должен быть установлен на «never» (что должно привести к тому, что очередь будет жить вечно, если ссылка федерации не будет удалена на стороне ниже по потоку).Наши сообщения также публикуются как постоянные.
Только журналы в вышестоящей системе имеют соответствующую информацию об этой проблеме во время перезапуска канала федерации.Фрагмент упомянут ниже.В нем говорится, что очередь инициализируется с глубины «0».
Я хочу задать следующие вопросы -
- Правильно ли наше понимание федерации (в контексте того, что упоминаетсявыше)?У нас нет способа воспроизвести проблему.Но знает ли кто-нибудь причину этого или какие-либо пропущенные настройки на нашем конце?
- При каждом перезапуске "ссылки федерации" на стороне нисходящего потока всегда ли воссоздается очередь "федерации" на стороне восходящего потока?
- Есть ли команда для просмотра отметки времени создания таких объектов, как очереди и обмены?
- Какими рекомендациями или методами мы можем следовать, чтобы гарантировать, что очередь федерации не будет удалена?
Версии RabbitMQ: - Upstream: RabbitMQ 3.6.1, Erlang R16B03-1 - Downstream: RabbitMQ 3.6.15, Erlang 20.3.4
Зарегистрировать фрагмент из вышестоящего узла rabbitmq.Других релевантных журналов не найдено.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
= ПРЕДУПРЕЖДАЮЩИЙ ОТЧЕТ ==== 8 октября 2018 г. :: 14: 57: 38 ===
закрытие соединения AMQP <0.1688.0> (: 51364 ->: 5672):
клиент неожиданно закрыл TCP-соединение
= ИНФОРМАЦИОННЫЙ ОТЧЕТ ==== 8 октября 2018 года :: 14: 58: 07 ===
принятие соединения AMQP <0.521.123> (: 46659 ->: 5672)
= ИНФОРМАЦИОННЫЙ ОТЧЕТ ==== 8 октября 2018 года :: 14: 58: 08 ===
Зеркальная очередь 'federation: order.exch ->' in vhost 'production': Добавление зеркала на узле 'rabbit @ upstream-hostname': <7719.25968.3282>
= ИНФОРМАЦИОННЫЙ ОТЧЕТ ====8-окт-2018 :: 14: 58: 08 ===
Зеркальная очередь 'federation: order.exch ->' в vhost 'production': Синхронизация: 0 сообщений для синхронизации
= ИНФОРМАЦИОННЫЙ ДОКЛАД ==== 8-Oct-2018 :: 14: 58: 08 ===
Зеркальная очередь 'federation: order.exch ->' in vhost 'production': Синхронизация: размер пакета:4096
= ИНФОРМАЦИОННЫЙ ОТЧЕТ ==== 8 октября 2018 года :: 14: 58: 08 ===
Зеркальная очередь 'федерация: order.exch ->' in vhost 'production': Синхронизация: все ведомые уже синхронизированы
= ОТЧЕТ ОБ ИНФОРМАЦИИ ==== 8 октября 2018 г. :: 14: 58: 09 ===
прием соединения AMQP <0.567.123>(: 46659 ->: 5672)
++++++++++++++++++++++++++++++++++++++++++++++++++++
Пожалуйста, дайте мне знать, если вам нужна дополнительная информация от моего конца, чтобы ответить на эти вопросы.