升级 RabbitMQ

升级策略

RabbitMQ 支持三种主要的升级策略。下面是它们的简要概述。每种策略都有一个专门的页面，提供更详细的信息。

滚动（原地）升级

提示

推荐使用此升级策略

滚动升级（也称为原地升级）是一种节点逐个升级的升级过程。有关更多详细信息，请参阅滚动升级指南页面，但主要步骤如下：

• 调查当前版本和目标版本之间是否存在滚动升级路径
  • 检查版本可升级性
  • 检查Erlang 版本要求
  • 检查发布说明
  • 验证所有稳定的功能标志均已启用
• 检查节点或集群状态良好，适合升级
  • 没有警报生效
  • 没有正在进行的队列或流副本同步操作
  • 系统负载合理
• 对于每个节点
  • 停止节点
  • 升级 RabbitMQ，如果适用，也升级 Erlang
  • 启动节点
  • 查看监控和健康检查数据，以评估已升级节点和集群的健康状况和恢复情况
• 所有节点升级完成后，启用新版本中引入的稳定功能标志

蓝绿部署

提示

此升级策略是最安全的选择。对于无法进行滚动升级的情况，或当额外安全性特别重要时，推荐使用此策略。

蓝绿部署策略的优势在于提高了升级过程的安全性，但代价是临时增加了基础设施的占用。安全性体现在操作员可以通过将应用程序切换回旧集群来中止升级。

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

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

如果可以接受一些停机时间，蓝绿策略也有一个简化的版本

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

增长后收缩升级

危险

此升级策略会更改副本身份，可能导致节点之间进行大量不必要的數據传输，并且只有在采取重要预防措施的情况下才安全。因此，强烈反对在整个集群范围内使用此策略进行升级。

提示

然而，此策略对于替换单个集群节点而言，可能是一个合理的选择。

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

• 调查当前版本和目标版本是否可以集群化
  • 检查版本可升级性；如果旧版本和新版本之间不支持滚动升级，也意味着这两个版本不能在单个集群中共存。
  • 检查Erlang 版本要求
  • 检查发布说明
• 向集群添加一个新节点 D（以便节点 D 可以加入集群）
• 在新节点上为每个仲裁队列和每个流放置一个新的副本
• 检查节点或集群状态良好
  • 没有警报生效
  • 没有正在进行的队列或流副本同步操作
  • 系统负载合理
• 使用 rabbitmqctl forget_cluster_node 从集群中移除节点 A
• 对其他节点重复上述步骤；在三节点集群示例中，集群现在应由节点 D、E 和 F 组成。
• 启用新版本中引入的稳定功能标志

此策略仅建议用于替换必须退役的单个节点，而不是升级多个节点。

RabbitMQ 版本可升级性

从 RabbitMQ 3.13.x 升级到 RabbitMQ 4.0.x 和 RabbitMQ 4.1.x 都受支持。

所有稳定的功能标志必须在升级之前启用，否则升级可能会失败。

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

发布系列可升级性

以下显示了支持的升级路径。

从	到
4.0.x	4.1.x
3.13.x	4.1.x
3.13.x	4.0.x
3.12.x	3.13.x
3.11.18	3.12.x
3.10.x	3.11.x
3.9.x	3.10.x
3.8.x	3.9.x
3.7.18	3.8.x

注意

RabbitMQ 3.13 包含对 Khepri 的实验性支持。然而，自那时以来引入了重大更改，导致 3.13 中的 Khepri 支持与 4.x 不兼容。因此，启用了 Khepri 的 RabbitMQ 3.13 不能升级到 4.x。蓝绿部署在此情况下仍然可以使用，因为它在技术上不是升级，而是迁移到一个新的集群。

Erlang 版本要求

请参阅Erlang 版本要求指南，了解给定 RabbitMQ 版本所需的最低 Erlang 版本和最高支持的 Erlang 版本。

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

我们建议您在升级 RabbitMQ 的同时升级 Erlang。

版本间的插件兼容性

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

管理插件升级

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

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

升级注意事项

系统资源使用量的变化

在升级期间和之后，连接和队列将在节点之间以不同的方式进行平衡：随着节点的下线，连接将在剩余节点上重新建立，并且队列领导者将被重新选举。确保您的集群能够在部分节点（通常是一个）停机进行升级时承受工作负载，这一点很重要。建议在低流量时段执行升级。

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

升级单节点安装

与升级多节点集群相比，升级单节点安装没有根本区别。

升级开发环境

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

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

降级

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

尽管如此，降级在某些版本之间实际上是可行的，特别是当它们仅在补丁版本上有所不同时。但这不能保证：有些补丁版本甚至无法降级到紧接其前的补丁版本。

备份

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

何时重启节点

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

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

bash

# 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

PowerShell

# 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.bat check_if_node_is_quorum_critical

例如，考虑一个具有节点 A、B 和 C 以及一些仲裁队列的三节点集群。如果节点 B 当前处于停机状态，则在节点 A 或 C 上执行此检查将失败，因为如果 A 或 C 停机，将只有一个节点正在运行（因此，将没有多数）。当节点 B 重新联机时，同一检查将成功。

在自动化升级过程时，您可以使用 rabbitmq-upgrade await_online_quorum_plus_one 命令来阻止节点关机过程，直到有足够的节点运行以维持多数。请注意，某些部署选项已包含此检查 - 例如，在使用Cluster Operator在 Kubernetes 上运行 RabbitMQ 时，这已经是 preStop hook 的一部分。

重新平衡队列领导者

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

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

bash

rabbitmq-queues rebalance all

PowerShell

rabbitmq-queues.bat rebalance all

全停式升级

在执行升级时，无需停止集群中的所有节点。

维护模式

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

当节点处于维护模式时，它将无法提供客户端流量，并将尝试尽可能安全地转移其大部分职责。

目前这包括以下步骤：

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

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

此功能预计会根据 RabbitMQ 操作员、用户以及 RabbitMQ 核心团队自身的反馈进行发展。

处于维护模式的节点应在短时间窗口内（例如 5-30 分钟）关闭、升级或重新配置并重新启动。不期望节点会永久或长时间处于此模式。

启用维护模式

要将节点置于维护模式，请使用 rabbitmq-upgrade drain。

bash

rabbitmq-upgrade drain

PowerShell

rabbitmq-upgrade.bat drain

禁用维护模式

提示

重启会自动将节点从维护模式中退出。

可以通过使用 rabbitmq-upgrade revive 命令来恢复处于维护模式的节点，即将其带回其常规运行状态。

bash

rabbitmq-upgrade revive

PowerShell

rabbitmq-upgrade.bat revive

该命令用于（在可能的情况下）回滚 drain 命令的效果。只有当您决定无法按计划重启节点时，才需要运行此命令。

在节点重新启动/升级后，不必恢复节点，因为重启会自动将节点从维护模式中退出。

检查维护状态

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

应用程序中处理节点重启

为了减少或消除停机时间，应用程序（生产者和消费者）应能够处理服务器发起的连接关闭。一些客户端库提供自动连接恢复功能来帮助实现这一点。

• Java 客户端
• .NET 客户端
• Bunny (Ruby)

在大多数客户端库中，都有处理连接关闭的方法，例如

• Pika (Python)
• Go

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

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

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

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

此算法涵盖了大多数用例，并且是上述自动恢复功能实现的原理。

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

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

• Java 客户端
• .NET 客户端
• Bunny