rabbitmqctl reset 必须先执行 rabbitmqctl stop_app，否则报错；它会通知集群后清空 mnesia 数据，而 force_reset 跳过通知直接清库；重置后所有用户、vhost、队列等全部丢失，需手动重建或导入定义；集群中宕机节点须在其他节点用 forget_cluster_node 剔除。
reset 命令必须配合 stop_app 使用
rabbitmqctl reset 不是独立生效的命令，它要求节点应用已停止。直接执行会报错：Node is not running 或 not_running。正确顺序只能是：rabbitmqctl stop_app → rabbitmqctl reset → rabbitmqctl start_app。漏掉 stop_app 是最常踩的坑，尤其在脚本中硬编码 reset 却没检查前置状态。
reset 和 force_reset 的本质区别
rabbitmqctl reset 会尝试与集群中其他磁盘节点通信，通知“我要退出”，避免被误判为故障节点；而 rabbitmqctl force_reset 完全跳过这一步，直接清空本地 Mnesia 数据库。只有当节点无法联系集群、或数据库严重损坏（比如 mnesia 目录权限错乱、文件残留导致启动失败）时才用 force_reset。误用 force_reset 可能导致集群元数据不一致，后续 join_cluster 失败。
重置后不是“干净重启”，而是“空白状态”
执行 reset 后，以下内容全部丢失：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 所有用户（
guest也不剩） - 所有虚拟主机（
/也被删掉） - 所有队列、交换机、绑定关系
- 所有策略（
ha-mode、expires等） - 所有权限配置
它不会恢复任何历史配置，也不会保留 /etc/rabbitmq/ 下的配置文件——那些只是启动时读取的模板，真正运行态数据全在 /var/lib/rabbitmq/mnesia/。所以重置后必须手动重建用户、vhost、权限，或用 rabbitmqctl import_definitions 导入 JSON 配置。
集群中剔除节点，别只靠 reset
如果节点还活着，reset 是标准做法；但如果节点已宕机、无法登录，就不能在它本地执行 reset。此时必须在其他存活节点上运行：rabbitmqctl forget_cluster_node rabbit@node2。这个命令会从集群元数据里彻底抹掉该节点记录。否则即使你删了它的磁盘数据，重启后它仍会试图加入旧集群，引发脑裂或启动卡死。很多团队卡在这里：反复重置宕机节点，却忘了在健康节点上先 forget。
rabbitmqctl list_vhosts 和 rabbitmqctl list_users 的输出是否符合预期。
