出现问题后重新启动联合 link 时，RabbitMQ 联合队列被自动删除
RabbitMQ federation queue got auto-deleted when restarted federation link after a problem
我们有两个 RabbitMQ 集群。一个用作上游，另一个用作下游。每个集群有 3 个节点。我们使用 RabbtitMQ - Federation 接收在上游集群的订单交换上发布到下游集群的消息。
这在过去 6 个月以来一直运行良好。突然在 10 月 4 日，我们在上游集群上收到集群分区错误。这是由于集群中的一个系统挂起超过一分钟。我们在系统日志中看到了关于此的重复信息，并暂时关闭了该系统。上游集群现在 运行 作为一个双节点集群。当时没有注意到，但是在 10 月 8 日，我们意识到在下游节点上，自 10 月 4 日以来我们没有收到任何订单消息。
经过进一步调查，我发现下游集群上的联邦 link 仍显示为 运行，但自动创建的 "federation" 队列上累积了 87000 多条消息上游集群。为了检索这些消息，我从下游集群重新启动了联邦 link。但出乎意料的是，我在门户网站上看到 "federation" 队列被删除并重新创建，将那 87000 多条消息也带入了 space 的黑暗中。从那时起我们开始收到任何新消息，但旧消息就丢失了。
在实施解决方案之前，我们通过一个接一个地关闭两个集群来对此进行了一些 POC。每次，联合队列都能够保留持久消息。只要两个集群都处于正确状态，下游联盟 link 就能够获取这些消息。因此，我们得出的结论是，只要上游节点上的 "federation" 队列可用，下游节点上的 "federation link" 就应该挑选消息；因此我们从未预料到这个问题。
我们既没有在联合配置上设置 x-expire 和 x-message-ttl 参数，应用程序也没有在发布消息时设置这些参数。我们只在联合配置中使用 "trust-user-id": false、URI（所有 3 个集群节点）和交换名称。 Rest all 是默认的，这意味着联合队列上的 "x-expire" 应该设置为 "never"（这应该会导致队列永远存在，除非联合 link 在下游端被删除）。我们的消息也作为持久性发布。
在联邦link重启期间，只有上游系统的日志有关于这个问题的相关信息。该片段在下面提到。它说队列从“0”深度开始初始化。
我想请教以下问题-
- 我们对联邦的理解是否正确（在上面提到的上下文中）？
我们没有办法重现该问题。但是有人知道它的原因或我们这边缺少的任何设置吗？
- 在下游侧每次 "federation link" 重新启动时，是否总是在上游侧重新创建 "federation" 队列？
- 是否有命令可以查看队列和交换器等对象的创建时间戳？
- 我们可以遵循哪些最佳实践或技术来确保联合队列不被删除？
RabbitMQ 版本：
- 上游：RabbitMQ 3.6.1，Erlang R16B03-1
- 下游：RabbitMQ 3.6.15，Erlang 20.3.4
来自上游 rabbitmq 节点的日志片段。没有找到其他相关日志。
+++++++++++++++++++++++++++++++++++++++++++++ +++++++++
=警告报告==== 2018 年 10 月 8 日::14:57:38 ===
关闭 AMQP 连接 <0.1688.0> (:51364 -> :5672):
客户端意外关闭了 TCP 连接
=信息报告==== 2018 年 10 月 8 日::14:58:07 ===
正在接受 AMQP 连接 <0.521.123> (:46659 -> :5672)
=信息报告==== 2018 年 10 月 8 日::14:58:08 ===
vhost 'production' 中的镜像队列 'federation: order.exch -> '：在节点 'rabbit@upstream-hostname' 上添加镜像：<7719.25968.3282>
=信息报告==== 2018 年 10 月 8 日::14:58:08 ===
vhost 'production' 中的镜像队列 'federation: order.exch -> '：正在同步：要同步 0 条消息
=信息报告==== 2018 年 10 月 8 日::14:58:08 ===
vhost 'production' 中的镜像队列 'federation: order.exch -> '：正在同步：批处理大小：4096
=信息报告==== 2018 年 10 月 8 日::14:58:08 ===
vhost 'production' 中的镜像队列 'federation: order.exch -> '：正在同步：所有从站已同步
=信息报告==== 2018 年 10 月 8 日::14:58:09 ===
正在接受 AMQP 连接 <0.567.123> (:46659 -> :5672)
+++++++++++++++++++++++++++++++++++++++++++++ +++++++
如果您需要我提供更多信息来回答这些问题，请告诉我。
感谢所有查看此查询的人。回答这个问题，因为它可能会在将来帮助其他人。
我们与供应商开了个案。他们试图在他们的实验室中复制这一点，但未能成功。目前我们不确定是什么导致了这个问题。为了查看队列何时创建，需要启用和监听另一个插件事件交换。
Rabbitmq 看起来像是一个非常适合小型 apps/micro 服务的产品，但在分布式 messaging/clustering 方面就不是那么好了。在过去，我们也看到过由于集群问题导致消息丢失的情况。这只是我根据目前的经验得出的意见，我以前也错了。
我们有两个 RabbitMQ 集群。一个用作上游，另一个用作下游。每个集群有 3 个节点。我们使用 RabbtitMQ - Federation 接收在上游集群的订单交换上发布到下游集群的消息。
这在过去 6 个月以来一直运行良好。突然在 10 月 4 日，我们在上游集群上收到集群分区错误。这是由于集群中的一个系统挂起超过一分钟。我们在系统日志中看到了关于此的重复信息，并暂时关闭了该系统。上游集群现在 运行 作为一个双节点集群。当时没有注意到，但是在 10 月 8 日，我们意识到在下游节点上，自 10 月 4 日以来我们没有收到任何订单消息。
经过进一步调查，我发现下游集群上的联邦 link 仍显示为 运行，但自动创建的 "federation" 队列上累积了 87000 多条消息上游集群。为了检索这些消息，我从下游集群重新启动了联邦 link。但出乎意料的是，我在门户网站上看到 "federation" 队列被删除并重新创建，将那 87000 多条消息也带入了 space 的黑暗中。从那时起我们开始收到任何新消息，但旧消息就丢失了。
在实施解决方案之前，我们通过一个接一个地关闭两个集群来对此进行了一些 POC。每次，联合队列都能够保留持久消息。只要两个集群都处于正确状态，下游联盟 link 就能够获取这些消息。因此，我们得出的结论是，只要上游节点上的 "federation" 队列可用，下游节点上的 "federation link" 就应该挑选消息；因此我们从未预料到这个问题。
我们既没有在联合配置上设置 x-expire 和 x-message-ttl 参数，应用程序也没有在发布消息时设置这些参数。我们只在联合配置中使用 "trust-user-id": false、URI（所有 3 个集群节点）和交换名称。 Rest all 是默认的，这意味着联合队列上的 "x-expire" 应该设置为 "never"（这应该会导致队列永远存在，除非联合 link 在下游端被删除）。我们的消息也作为持久性发布。
在联邦link重启期间，只有上游系统的日志有关于这个问题的相关信息。该片段在下面提到。它说队列从“0”深度开始初始化。
我想请教以下问题-
- 我们对联邦的理解是否正确（在上面提到的上下文中）？ 我们没有办法重现该问题。但是有人知道它的原因或我们这边缺少的任何设置吗？
- 在下游侧每次 "federation link" 重新启动时，是否总是在上游侧重新创建 "federation" 队列？
- 是否有命令可以查看队列和交换器等对象的创建时间戳？
- 我们可以遵循哪些最佳实践或技术来确保联合队列不被删除？
RabbitMQ 版本： - 上游：RabbitMQ 3.6.1，Erlang R16B03-1 - 下游：RabbitMQ 3.6.15，Erlang 20.3.4
来自上游 rabbitmq 节点的日志片段。没有找到其他相关日志。
+++++++++++++++++++++++++++++++++++++++++++++ +++++++++
=警告报告==== 2018 年 10 月 8 日::14:57:38 ===
关闭 AMQP 连接 <0.1688.0> (:51364 -> :5672):
客户端意外关闭了 TCP 连接
=信息报告==== 2018 年 10 月 8 日::14:58:07 ===
正在接受 AMQP 连接 <0.521.123> (:46659 -> :5672)
=信息报告==== 2018 年 10 月 8 日::14:58:08 ===
vhost 'production' 中的镜像队列 'federation: order.exch -> '：在节点 'rabbit@upstream-hostname' 上添加镜像：<7719.25968.3282>
=信息报告==== 2018 年 10 月 8 日::14:58:08 ===
vhost 'production' 中的镜像队列 'federation: order.exch -> '：正在同步：要同步 0 条消息
=信息报告==== 2018 年 10 月 8 日::14:58:08 ===
vhost 'production' 中的镜像队列 'federation: order.exch -> '：正在同步：批处理大小：4096
=信息报告==== 2018 年 10 月 8 日::14:58:08 ===
vhost 'production' 中的镜像队列 'federation: order.exch -> '：正在同步：所有从站已同步
=信息报告==== 2018 年 10 月 8 日::14:58:09 ===
正在接受 AMQP 连接 <0.567.123> (:46659 -> :5672)
+++++++++++++++++++++++++++++++++++++++++++++ +++++++
如果您需要我提供更多信息来回答这些问题，请告诉我。
感谢所有查看此查询的人。回答这个问题，因为它可能会在将来帮助其他人。
我们与供应商开了个案。他们试图在他们的实验室中复制这一点，但未能成功。目前我们不确定是什么导致了这个问题。为了查看队列何时创建，需要启用和监听另一个插件事件交换。
Rabbitmq 看起来像是一个非常适合小型 apps/micro 服务的产品，但在分布式 messaging/clustering 方面就不是那么好了。在过去，我们也看到过由于集群问题导致消息丢失的情况。这只是我根据目前的经验得出的意见，我以前也错了。