如何实现单节点RabbitMQ到Bitnami K8s集群全量迁移

所有迁移操作必须先在测试环境完整跑通全流程，再在生产环境操作，严禁直接在生产环境上手试。

一、迁移前准备 #

• 严格对齐源端、目标端RabbitMQ版本：源端跑什么版本，目标Bitnami部署的集群就用什么版本，哪怕差一个小补丁版本都可能出现Mnesia数据格式不兼容，Bitnami Chart部署时直接在values.yaml里把image.tag改成和源端完全一致的版本号就行。
• 提前在K8s集群部署好空的3节点Bitnami RabbitMQ集群，先不接任何业务，在任意Pod里执行rabbitmqctl cluster_status确认三个节点都成功加入集群、状态为running，提前把镜像队列/仲裁队列的默认策略配成和源端一致，开启管理插件方便可视化核对。
• 给源端做全量备份：有虚拟机/物理机快照条件的直接打磁盘快照，没快照条件的先临时停掉源端RabbitMQ进程，把/var/lib/rabbitmq/mnesia/整个目录打包存到其他路径，操作失误随时能回滚。
• 别踩最常见的坑：绝对不能直接把源端Mnesia数据目录拷到目标节点硬启动，Mnesia强绑定节点主机名，主机名不匹配的情况下直接拷数据，要么启动失败，要么数据文件直接损坏。

二、具体迁移步骤 #

给你两个可选方案，新手优先选第一个，出错概率极低，完全不依赖主机名匹配。

方案1：官方定义导出+Shovel同步（新手首选，无主机名依赖） #

这个方案全程用RabbitMQ官方自带工具，不碰底层数据的主机名绑定逻辑，所有配置、消息都通过标准协议同步，和两端主机名是什么完全没关系。

1. 源端停业务连接：先停所有连源端的生产者进程，等队列里没有在途消息后，再停所有消费者进程，在源端管理界面看Connections、Channels列表为空，确认源端没有新数据写入。
2. 导出源端全量元数据：在源服务器执行命令，导出所有vhost、用户、权限、交换机、队列、绑定、策略等配置：

   rabbitmqctl export_definitions /tmp/rabbitmq-defs.json
   

   注意：这个导出的json文件只包含配置元数据，不包含队列里的存量持久化消息。
3. 导入配置到目标集群：先把导出的json文件拷到目标集群任意一个RabbitMQ Pod里：

   kubectl cp /tmp/rabbitmq-defs.json <目标rabbitmq任意pod名称>:/tmp/defs.json -n <rabbitmq所在命名空间>
   

   进Pod执行导入命令：

   kubectl exec -it <目标rabbitmq pod名称> -n <命名空间> -- rabbitmqctl import_definitions /tmp/defs.json
   

   导入完去目标集群管理界面逐项核对，确认所有配置和源端完全一致，没有遗漏。
4. 同步存量消息：在目标集群所有节点开启Shovel插件（Bitnami部署可以直接在values.yaml的plugins字段里加rabbitmq_shovel、rabbitmq_shovel_management，不用每个节点手动开），在管理界面进入Shovel Management页新建同步任务：
   • 源地址填源端RabbitMQ的AMQP连接串，格式为amqp://<源端用户名>:<源端密码>@<源端IP>:5672/<vhost路径，根vhost填%2f>，多vhost就每个vhost建一个任务
   • 源端类型选Queue，队列名填*即可匹配该vhost下所有队列
   • 目标端选当前目标集群本地，队列保持和源端同名
   • 启动任务后等待同步完成：看源端所有队列消息数降到0，目标端对应队列消息数和源端迁移前数值一致，就说明消息同步完成。
5. 切流量：先把消费者切到目标集群，确认消费逻辑正常，再把生产者切到目标集群，观察30分钟以上，看消息收发、队列堆积、节点指标有没有异常。

方案2：冷数据迁移改节点名（适合TB级超大消息量场景，操作需谨慎） #

如果你的队列存量消息特别大，用Shovel同步速度太慢，可以选这个方案直接迁底层Mnesia数据，操作前必须确认已经做了全量数据备份。

1. 完全停掉源端RabbitMQ进程，执行ps aux | grep rabbitmq确认没有残留进程，打包整个Mnesia目录：

   tar -zcf /tmp/rabbitmq-mnesia.tar.gz /var/lib/rabbitmq/mnesia/
   

2. 把目标K8s集群里的3节点RabbitMQ集群缩容到0副本，清空所有持久卷里的原有Mnesia数据（避免旧数据冲突）。
3. 把源端打的Mnesia压缩包拷到目标集群规划为种子节点的Pod（一般选序号0的节点）对应的持久卷目录，解压覆盖，把所有文件权限改成1001（Bitnami镜像默认用UID 1001的用户运行RabbitMQ，权限不对会启动失败）。
4. 只启动这个种子节点Pod，这时候因为节点名和源端不一致，启动会报节点不匹配的错，进Pod执行重命名命令：

   rabbitmqctl rename_cluster_node <源端完整节点名，格式为rabbit@<源端主机名>> <目标种子节点完整名，格式为rabbit@rabbitmq-0.rabbitmq-headless.<命名空间>.svc.cluster.local>
   

   目标节点名直接抄Pod启动日志里打印的当前节点名就行，不用自己拼。
5. 等种子节点正常启动，执行rabbitmqctl list_queues确认所有队列、消息都存在，状态正常，再把另外两个RabbitMQ副本扩容到对应数量，两个新节点会自动加入集群，同步全量数据。
6. 等所有节点数据同步完成，队列主副本分布正常，核对完所有配置、消息数和源端一致，就可以切业务流量。

三、迁移后必做校验 #

• 核对vhost、用户、权限、交换机、队列、绑定、策略的数量、配置和源端完全一致
• 核对所有持久化队列的消息数和源端迁移前的数值一致，没有丢消息
• 发送测试消息验证生产、消费全流程正常，确认没有消息重复、无法路由的问题
• 持续观察集群内存、磁盘占用、连接数、通道数指标，看节点日志有没有持续报错

内容的提问来源于stack exchange，提问作者devops-admin