#RabbitMQ 工作负载的故障切换和回切

本指南描述了应用侧在主 RabbitMQ 环境切换到已准备好的备用环境时的操作步骤，以及在主站点恢复可用后将工作负载切回主站点的操作步骤。

本文假定拓扑、访问控制、TLS 资料和消息迁移机制已经准备就绪。它不能替代灾难恢复设计。请将其与工作负载特定的 DR 文档一并使用，例如 RabbitMQ Disaster Recovery with Federated Exchanges。

#前提条件

在对工作负载执行故障切换之前，请确保满足以下条件：

1. 备用环境已具备所需的 virtual hosts、用户、权限、exchanges、queues、bindings、policies，以及 Kubernetes Secret 对象。
2. 应用程序已记录切换 broker 端点、凭据和 TLS trust material 的方法。
3. 你已明确该事件是计划内故障切换、非计划故障切换，还是恢复后的回切。
4. 你已明确消息如何在站点之间复制或回放，例如通过 Federation、Shovel、应用双写发布或业务层回放。

#计划内故障切换

当主站点仍可访问，并且你可以控制切换顺序时，请使用计划内故障切换。

#1. 减少向主站点的新写入

如果可能，在切换消费者之前先停止或清空生产者。这可以限制切换窗口期间的消息分歧。

#2. 验证备用环境

在迁移流量之前，先检查备用集群：

• RabbitMQ Pods 已就绪。
• RabbitmqCluster 阶段为 Active。
• 所需的用户、virtual hosts 和权限已存在。
• 所需的 exchanges、queues、bindings 和 policies 已存在。
• 队列堆积量的新鲜度和复制延迟对该工作负载而言可接受。
• 如果使用了 TLS 监听器，则其与客户端配置匹配。

#3. 切换消费者

当你希望备用站点先开始清理已复制的堆积量，然后再将新的生产者重定向到那里时，应先将消费者指向备用环境。

#4. 切换生产者

在备用站点上的消费者准备就绪后，将生产者更新为发布到备用 RabbitMQ 地址和凭据。

#5. 验证备用站点上的消息流

验证以下内容：

• 生产者可以成功发布。
• 消费者已连接并正在接收消息。
• 队列堆积量表现符合预期。
• 磁盘和内存告警保持清除状态。

#非计划故障切换

当主站点不可用或无法顺利清空时，请使用非计划故障切换。

#1. 评估数据新鲜度

如果你使用的是异步复制，例如 Federation 或 Shovel，请在备用站点启动应用之前，先确定可能的消息延迟。

#2. 以幂等性支持启动消费者

由于在故障期间无法准确确定切换点，可能会发生重复投递。消费者应准备好检测或容忍重复消息。

#3. 将生产者切换到备用站点

更新应用程序的端点、凭据和 trust material，以使用备用环境。

#4. 跟踪堆积量和告警

在备用站点承载工作负载期间，监控备用队列深度、消费者延迟和 broker 告警。

#回切操作步骤

回切是一个单独的受控变更。在主环境健康且拓扑已更新之前，不要将流量切回主站点。

#1. 重建或验证主环境

在执行回切之前，请验证主侧以下内容：

• RabbitMQ 版本和插件与预期发布版本匹配。
• virtual hosts、用户、权限、exchanges、queues、bindings、policies 和参数正确。
• TLS 证书和 Kubernetes Secret 对象是最新的。
• 在需要时，复制或回放方向已更新为向主站点补充数据。

#2. 确定消息切回策略

在将流量切回之前，请选择以下策略之一：

• 先完全清空备用堆积量，然后再切换流量。
• 冻结生产者，迁移剩余堆积量，然后再切换。
• 接受与该工作负载相关的回放或重复窗口，并在计划的切换点进行切换。

#3. 先将消费者切回

当你希望主站点先清理恢复后的堆积量，然后再将新的生产者重定向到那里时，应先迁移消费者。

#4. 再将生产者切回

在主站点上的消费者稳定后，将生产者重定向回主站点。

#5. 验证稳定状态

确认以下内容：

• 主站点上的队列深度稳定。
• 消费者不再从备用站点读取。
• 复制或迁移任务已根据 DR 设计停止或反向执行。
• 告警和仪表板反映新的活动站点。

#验证清单

在故障切换和回切场景中，都应使用以下清单：

#相关信息

• RabbitMQ Disaster Recovery with Federated Exchanges
• Manage RabbitMQ Definitions
• Check RabbitmqCluster Status