必须用rabbitmqctl set_policy配置镜像策略，web ui仅作用于当前节点内存视图；需确保.erlang.cookie三节点完全一致且权限400；节点加入集群后须执行stop_app && start_app重载应用层；验证需检查list_queues synchronised_slave_pids非空及故障转移实效。
要让 RabbitMQ 集群真正具备高可用能力，光搭好集群远远不够——必须正确配置镜像队列，并验证故障转移是否自动生效。核心在于策略落地、节点协同和状态可观测，三者缺一不可。
策略必须用命令行设置，Web UI 不生效
Web 控制台里添加的镜像策略只是临时视图，不会写入集群元数据，其他节点完全感知不到。真正起作用的只能是 rabbitmqctl set_policy 命令。
- 正确示例：
rabbitmqctl set_policy ha-two "^mirror_" '{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}' -p /myvhost - pattern 必须是正则，
^mirror_表示匹配以 mirror_ 开头的队列名；不能写成*或空字符串 - 策略名只允许字母、数字、连字符和下划线，比如
ha-prod-policy合法，ha@prod会失败 - 执行前确认 vhost 存在（
-p /myvhost），否则策略静默失效，查不到也不报错
节点加入后必须重载应用层，不能只 join
执行 rabbitmqctl join_cluster rabbit@node1 只完成 Erlang 节点握手，RabbitMQ 应用层拓扑还没加载，镜像队列无法选举主从，新策略也不会同步。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 加入集群后，必须在每个新节点上依次执行：
rabbitmqctl stop_app && rabbitmqctl start_app - 切勿直接
systemctl restart rabbitmq-server—— 强制终止 Erlang 节点可能导致集群握手卡死 - 验证方式：
rabbitmqctl list_queues name synchronised_slave_pids，非空说明镜像已就绪
.erlang.cookie 是集群通信的密钥
三节点的 /var/lib/rabbitmq/.erlang.cookie 文件内容必须一字不差，权限严格为 400（仅 owner 可读）。
- 校验命令：
md5sum /var/lib/rabbitmq/.erlang.cookie，三台输出必须完全一致 - 常见破坏场景：用 vim 编辑后插入 BOM、scp 复制时末尾多空行、cat 拼接导致换行符异常
- 权限错误时日志会明确报错：
Cookie file ... must be accessible by owner
故障转移需主动验证，不能只看 cluster_status
rabbitmqctl cluster_status 显示所有节点在线，不代表镜像队列已正常工作。真实可用性要看主从同步状态和故障切换表现。
- 模拟主节点宕机：
systemctl stop rabbitmq-server在 master 所在节点执行 - 观察消费者是否短暂断连后自动重连新主节点；检查
list_queues中synchronised_slave_pids是否更新 - 若新主未自动选出，常见原因是镜像节点未 fully synced（可通过
list_queues的state字段判断） - 极端情况（如主节点彻底丢失），可用
rabbitmqctl forget_cluster_node --offline强制剔除离线节点，再重建镜像
