跳至主内容
版本:4.2

先增长后收缩升级

注意

此策略涉及节点身份更改和将副本转移到新添加的节点。

对于具有大型数据集的仲裁队列和流,这意味着集群将经历大量的网络流量和磁盘 I/O 峰值,而滚动原地升级则不会。

考虑改用原地升级蓝绿部署升级

危险

为了安全地执行先增长后收缩升级,必须采取几项预防措施。

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

  • 将新节点 D 添加到集群。
  • 使用 `rabbitmq-queues grow` 等命令将每个仲裁队列和每个流的新副本放置到新节点上。
  • 检查集群状态是否良好:没有警报生效,没有正在进行的队列或流副本同步操作,并且系统在其他方面负载合理。
  • 使用 `rabbitmqctl forget_cluster_node` 从集群中移除节点 A。
  • 将新节点 E 添加到集群。
  • 使用 `rabbitmq-queues grow` 等命令将每个仲裁队列和每个流的新副本放置到新节点上。
  • 检查集群状态是否良好。
  • 使用 `rabbitmqctl forget_cluster_node` 从集群中移除节点 B。
  • 依此类推。

这种方法似乎在原地升级的相对简单性和蓝绿部署升级的安全性之间取得了很好的平衡。然而,实际上,这种策略具有与原地升级选项相似的特性。

  • 新添加的节点可能会影响现有的集群状态。
  • 在升级过程中,副本将在节点之间迁移。

此外,这种方法还有其独特的潜在风险。

  • 在升级过程中节点身份会发生变化,这可能会影响历史监控数据
  • 节点必须将其数据集传输到新添加的成员,这可能导致**网络流量和磁盘 I/O 大幅增加**。
  • 过早移除节点(见下文)可能导致部分仲裁队列和流的仲裁丢失。
危险

为了安全地执行先增长后收缩升级,必须采取几项预防措施。

为了安全地执行先增长后收缩升级,必须采取几项预防措施。

  • 在添加新节点并启动副本扩展过程后,必须给予该过程足够的时间来完成。
  • 在移除节点之前,必须运行健康检查,以确保该节点对于任何队列(或流)都不是仲裁关键的:也就是说,移除该节点不会使任何仲裁队列或流失去在线多数。
  • 必须使用 `rabbitmqctl forget_cluster_node` 显式地将节点从集群中移除。

特别不是为副本(节点)身份频繁更改且在单次集群升级期间所有副本都可以被转移并替换的环境设计的。

关键预防措施

要确定节点是否是仲裁关键节点,请使用以下健康检查

# 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

必须使用以下健康检查来确定是否存在任何剩余的初始仲裁队列副本日志传输。

# exits with a non-zero status if there are any ongoing initial quorum queue
# replica sync operations
rabbitmq-diagnostics check_if_new_quorum_queue_replicas_have_finished_initial_sync
提示

考虑一次添加和移除一个节点。

如果一次添加和移除多个节点,则必须对所有节点执行健康检查。一次移除多个节点更容易导致某些仲裁队列或流失去在线多数,因此强烈建议一次添加和移除一个节点。

© . This site is unofficial and not affiliated with VMware.