rabbitmq 3.13→4.2跨大版本升级必须采用“元数据导出+消息同步+双写过渡”三步闭环；export_definitions仅导出配置不丢消息，但新集群队列为空需靠shovel或双写补全消息，且须清空旧mnesia目录、启用khepri_db、确保节点名一致。
跨大版本升级（比如 3.13 → 4.2）时，直接停机覆盖安装大概率导致元数据不可读、队列无法启动、消息丢失——因为 Mnesia 和 Khepri 元数据存储不兼容，且 Raft 队列需重新声明。必须走「元数据导出 + 消息同步 + 双写过渡」三步闭环，缺一不可。
导出/导入 definitions.json 会丢消息吗？
不会丢消息，但只保元数据。rabbitmqctl export_definitions 和 rabbitmqctl import definitions.json 仅处理交换机、队列声明、绑定、用户、vhost 等配置，不包含任何队列里的消息体。这是安全的第一步，但绝不能当作迁移完成的标志。
- 导出前确保所有队列已持久化（
durable: true），否则非持久队列在节点重启后直接消失 - 导入后新集群中队列为空，需靠后续消息同步补全
- 若旧集群用了经典镜像队列（classic mirrored queues），而新集群启用了
khepri_db或 Quorum 队列，导入时需手动修改definitions.json中的"type": "quorum"字段，否则队列创建失败
消息怎么同步才不丢、不重？
用 rabbitmqctl copy_queue 不可行（仅限单节点、不支持跨集群、3.13+ 已弃用），真实生产环境必须用 Shovel 插件或双写方案。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- Shovel 同步推荐用
Local Shovel（4.2+ 新增）：通过内部 Erlang RPC 直接拉取，避免网络层 AMQP 解包重包，吞吐高、语义可控；配置里必须设"ack-mode": "on-confirm"，否则可能丢消息 - 如果业务允许灰度，优先选「双写双消费」：新旧集群同时收发，用时间戳或唯一 trace_id 去重；旧集群消费完积压后下线，风险最低
- 禁用 auto-delete 队列参与同步，它们会在无消费者时自动销毁，导致 Shovel 连接中断
升级后队列启动失败常见原因
不是配置错了，而是底层存储引擎或队列类型不匹配。4.2 默认启用 Khepri，但旧集群数据仍在 Mnesia 目录里，新节点不会自动转换。
- 检查日志是否含
Failed to start mnesia table或raft_log_not_found—— 表明节点试图用 Raft 加载 Mnesia 数据，必然失败 - 确认是否执行过
rabbitmqctl enable_feature_flag khepri_db，且集群所有节点都已生效（需rabbitmqctl stop_app && rabbitmqctl start_app） - 若从 3.x 升级到 4.2，不要复用旧
/var/lib/rabbitmq/mnesia目录；应清空该目录，让新节点初始化 Khepri 存储 - Quorum 队列不支持
x-max-length等经典参数，导入 definitions.json 前必须删掉或替换为x-quorum-initial-group-size
真正容易被忽略的是节点名称一致性：Mnesia 和 Khepri 都把节点名（如 rabbit@node1）硬编码在元数据里。如果新集群节点名和旧集群不同，即使 definitions.json 导入成功，Shovel 也无法连上源队列——此时必须用 rabbitmqctl rename_cluster_node 预先修正，而不是等报错再处理。
