跳至主要内容
版本：4.0

RabbitMQ 升级

重要

您只能从 RabbitMQ 3.13 升级到 RabbitMQ 4.0。

此外，您必须在升级**之前**启用功能标志。如果您错过了此步骤，升级将失败。

升级策略​

RabbitMQ 可以使用三种主要的升级策略。下面您将找到所有策略的简要概述。每个策略都有一个专门的页面，其中包含更详细的信息。

滚动（就地）升级​

提示

推荐使用此升级策略

滚动升级（也称为就地升级）是一种升级过程，其中节点一个接一个地升级。有关更多详细信息，请参阅滚动升级指南页面，但以下是一些主要步骤

蓝绿部署​

提示

此升级策略是最安全的选择。建议用于出于任何原因无法进行滚动升级或特别需要额外安全性的环境

蓝绿部署策略以牺牲暂时增加基础设施占用空间为代价，提供了使升级过程更安全的优势。安全方面来自于这样一个事实，即操作员可以通过将应用程序切换回旧集群来中止升级。

蓝绿升级通常涉及以下由部署工具或手动由操作员执行的步骤。有关这些步骤的更多详细信息，请参阅蓝绿部署指南

  • 使用所需版本部署新集群
  • 同步旧集群和新集群之间的元数据（除非应用程序可以声明自己的元数据）
  • 设置联合
  • 将消费者切换到新集群
  • 排出消息
  • 将发布者切换到新集群
  • 停用旧集群

如果可以接受某些停机时间，则还有蓝绿策略的简化版本

  • 使用目标版本部署新集群
  • 停止应用程序
  • 同步旧集群和新集群之间的元数据
  • 将所有消息从旧集群移动到新集群（例如，使用Shovel）
  • 重新配置应用程序以使用新集群
  • 启动发布者和消费者

增长然后收缩升级​

危险

此升级策略会更改副本标识，可能导致节点之间发生大量不必要的跨节点数据传输，并且只有在采取重要预防措施时才安全。因此，强烈建议不要使用。

增长然后收缩升级通常涉及以下步骤。考虑一个包含节点 A、B 和 C 的三个节点集群

  • 调查当前版本和目标版本是否可以一起集群
  • 将一个新节点，节点 D，添加到集群中（请注意，您可能需要禁用节点 D 才能加入集群的新功能标志）
  • 在新节点上放置每个仲裁队列和每个流的新副本
  • 检查节点或集群是否处于良好的状态
    • 没有警报生效
    • 没有正在进行的队列或流副本同步操作
    • 系统在其他方面处于合理的负载下
  • 使用 rabbitmqctl forget_cluster_node 从集群中删除节点 A
  • 对其他节点重复上述步骤；在 3 节点集群示例中，集群现在应由节点 D、E 和 F 组成
  • 启用新版本中引入的功能标志

可以一次添加和删除多个节点。

RabbitMQ 版本可升级性​

您只能从 RabbitMQ 3.13.x 升级到 RabbitMQ 4.0。

在尝试升级到 RabbitMQ 4.0 **之前**，请不要忘记在 3.13 上启用所有稳定的功能标志，否则升级将失败。

如果您尚未使用 RabbitMQ 3.13，请参阅下表以了解您的升级路径。

发行版系列可升级性

以下是支持的升级路径。

从到备注
3.13.x4.0.x升级**之前**必须启用所有功能标志
3.12.x3.13.x
3.11.183.12.x升级**之前**必须启用所有功能标志
3.10.x3.11.x升级**之前**必须启用所有功能标志
3.9.x3.10.x
3.8.x3.9.x
3.7.183.8.x
注意

RabbitMQ 3.13 包含对 Khepri 的实验性支持。但是，此后必须引入重大更改，导致 3.13 和 4.0 中的 Khepri 支持之间存在不兼容性。因此，启用了 Khepri 的 RabbitMQ 3.13 **无法**升级到 4.0。蓝绿部署仍然可以在这种情况下使用，因为从技术上讲它不是升级，而是迁移到一个新的集群。

Erlang 版本要求​

请参阅Erlang 版本要求指南以了解给定 RabbitMQ 版本的 Erlang 的最低要求版本和最大支持版本。

通常建议使用目标 RabbitMQ 版本支持的最新 Erlang 版本。

我们建议您与 RabbitMQ 一起升级 Erlang。

版本之间的插件兼容性​

RabbitMQ 发行版中包含的插件保证与它们分发的版本兼容。如果使用社区插件，则需要单独验证它们。

管理插件升级​

RabbitMQ 管理插件带有一个在浏览器中运行的 Web 应用程序。

升级集群后，强烈建议清除用于访问管理 UI 的域的浏览器缓存、本地存储、会话存储和 Cookie。否则，您可能会遇到 JavaScript 错误。

升级注意事项​

系统资源使用情况的变化​

在升级期间和之后，连接和队列将在节点之间以不同的方式进行平衡：随着节点的关闭，连接将在剩余节点上重新建立，并且队列领导者将重新选举。务必确保您的集群能够在某些（通常是一个）节点因升级而停机时维持工作负载。建议在流量较低的时间进行升级。

此外，不同版本的 RabbitMQ 可能会有不同的资源使用情况。在升级之前应考虑这一点：确保有足够的容量来使用新版本运行工作负载。始终查阅当前部署版本和目标版本之间所有版本的发布说明，以了解可能影响您的工作负载和资源使用情况的更改。

升级单节点安装​

升级单节点安装与升级多节点集群之间没有根本区别。

升级开发环境​

单节点部署通常是本地开发或测试环境。在这种情况下，如果存储在 RabbitMQ 中的消息不重要，则可能更容易简单地删除数据目录中的所有内容并启动新版本的新节点。实际上，它不再是升级，而是新版本的全新安装。

请注意，此过程将删除 RabbitMQ 中的所有数据（定义和消息），但这在开发/测试环境中通常不是问题。可以使用导出/导入保留定义。这种方法的好处是您可以轻松地在任何版本之间跳转，而无需担心兼容性和功能标志。

降级​

RabbitMQ 不正式支持降级 - 它们未经测试，不应依赖。想要额外安全的用户可以使用蓝绿部署方法，该方法允许切换回旧环境。

话虽如此，在某些版本之间降级在技术上是可行的，尤其是在它们仅在补丁版本上有所不同时。但是，这并不保证：有些补丁版本无法降级到即使是紧接其前的补丁版本。

备份​

强烈建议在升级之前备份节点的数据目录。

何时重新启动节点​

多个组件和功能依赖于节点仲裁的可用性。在最常见的三节点集群情况下，这意味着在升级期间应始终有两个节点可用。

RabbitMQ 提供了一个健康检查命令，如果目标节点上的任何仲裁队列、流队列或其他内部组件失去其仲裁，并且该节点将要关闭，则该命令将失败。

# exits with a non-zero code if any of the internal components, quorum queues or stream queues
# will lose online quorum should the target node be shut down;
# additionally, it will print which components and/or queues are affected
rabbitmq-diagnostics check_if_node_is_quorum_critical

例如，考虑一个包含节点 A、B 和 C 以及一些仲裁队列的三节点集群。如果节点 B 当前已关闭，则如果针对节点 A 或 C 执行此检查，则此检查将失败，因为如果 A 或 C 关闭，则将只有一个节点运行（因此，将没有仲裁）。当节点 B 重新上线时，相同的检查将成功。

在自动化升级流程时，可以使用rabbitmq-upgrade await_online_quorum_plus_one命令阻止节点关闭流程，直到有足够的节点运行以维持仲裁。请注意，某些部署选项已包含此检查 - 例如，当使用集群操作符在 Kubernetes 上运行 RabbitMQ 时，这已经是preStop钩子的一部分。

重新平衡队列领导者​

如果使用滚动或先增长后缩减的升级策略，则升级后队列领导者不会在节点之间均匀分布。重新平衡队列和流领导者有助于在所有集群节点之间分摊负载。

要重新平衡所有队列和流领导者副本，请运行

rabbitmq-queues rebalance all

完全停止升级​

无需停止集群中的所有节点即可执行升级。

维护模式​

维护模式是一种特殊的节点操作模式，在升级期间可能很有用。操作员使用下面介绍的一系列新的 CLI 命令显式地打开和关闭该模式。

当节点处于维护模式时，它将无法用于服务客户端流量，并将尝试在实际可行且安全的情况下转移尽可能多的职责。

目前这涉及以下步骤

  • 暂停所有客户端连接侦听器（不会接受新的客户端连接）
  • 关闭所有现有的客户端连接：预计应用程序将重新连接到其他节点并恢复
  • 转移目标节点上托管的所有仲裁队列的主副本，并阻止它们参与随后触发的 Raft 选举
  • 将节点标记为维护停机
  • 此时，节点关闭的破坏性最小，因为节点已将大部分职责转移出去。

处于维护模式的节点将不会被考虑用于新的主队列副本放置，无论队列类型是什么以及队列类型是否支持复制。

预计此功能将根据来自 RabbitMQ 操作员、用户和 RabbitMQ 核心团队自身经验的反馈而发展。

预计处于维护模式的节点将在短时间内（例如 5-30 分钟）关闭、升级或重新配置并重新启动。节点不应永久或长时间以这种模式运行。

启用维护模式​

要将节点置于维护状态，请使用rabbitmq-upgrade drain

rabbitmq-upgrade drain

禁用维护模式​

提示

重新启动会自动使节点退出维护模式。

可以使用rabbitmq-upgrade revive“恢复”处于维护模式的节点，即将其恢复到正常的运行状态。

rabbitmq-upgrade revive

该命令旨在（尽可能地）回滚drain命令的影响。只有在您决定无法按计划重新启动节点时才需要运行此命令。

节点重新启动/升级后，无需恢复节点，因为重新启动会自动使节点退出维护模式。

检查维护状态​

您可以通过运行rabbitmqctl cluster_status来检查集群中的任何节点是否处于维护模式。您还可以通过运行rabbitmqctl status来检查特定节点的状态。

处理应用程序中的节点重启​

为了减少或消除停机时间，应用程序（生产者和消费者）应该能够应对服务器发起的连接关闭。一些客户端库提供自动连接恢复来帮助解决此问题

在大多数客户端库中，都有一种方法可以对连接关闭做出反应，例如

许多应用程序的恢复过程遵循相同的步骤

  1. 重新连接
  2. 重新打开通道
  3. 恢复通道设置（例如basic.qos设置、发布者确认）
  4. 恢复拓扑

拓扑恢复包括以下操作，针对每个通道执行

  1. 重新声明应用程序声明的交换机
  2. 重新声明队列
  3. 恢复绑定（队列和交换机到交换机绑定）
  4. 恢复消费者

此算法涵盖了大多数用例，也是前面提到的自动恢复功能实现的内容。

在滚动升级期间，当节点停止时，连接到此节点的客户端将使用服务器发送的connection.close方法断开连接，并应重新连接到其他节点。这可以通过在集群前面使用负载均衡器或代理来实现，或者如果客户端库支持此功能，则可以通过指定多个服务器主机来实现。

许多客户端库支持主机列表，例如

© . All rights reserved.