Docker安装RabbitMQ并集群化操作步骤（MAC环境）

安装前须知

详见：https://blog.csdn.net/want_you_gogo/article/details/120930079

Docker安装rabbitmq并集群化操作步骤

查询docker社区网站 https://hub.docker.com/_/rabbitmq
本文选择3.9.7-management版本进行安装。

---

模拟跨三台机器（设置端口分别为5672&15672、5673&15673、5674&15674）安装 RabbitMQ为集群化做准备：rabbitmq-1、rabbitmq-2、 rabbitmq-3。

一、安装单节点rabbitmq服务

拉取rabbitmq镜像

docker pull rabbitmq:3.9.7-management

查看rabbitmq镜像是否拉取成功

docker images

启动单个rabbitmq节点镜像

docker run -d --name rabbitmq-1 -p 5672:5672 -p 15672:15672 --hostname rabbitmq-1 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' a6b922761c18

参数说明：
-d 后台进程运行
--hostname RabbitMQ主机名称
--name 容器名称
-p port:port 本地端口:容器端口
-p 15672:15672 http访问端口
-p 5672:5672 amqp访问端口
-e RABBITMQ_ERLANG_COOKIE 设置.erlang.cookie的值

查看单节点运行情况

docker ps | grep rabbitmq-1

打开管理页面测试

注意：rabbitmq默认UI界面管理插件是禁用的，如果不启用，docker启动rabbitmq镜像后无法访问15672端口

启用UI管理插件

# 查找rabbitmq的容器ID
docker ps | grep rabbitmq-1

# 命令进入容器，语法：docker exec -it 容器ID|容器名|CLI进程ID /bin/bash
docker exec -it 4d3fc2e81d78 /bin/bash
或
docker exec -it rabbitmq-1 /bin/bash
或
docker exec -it 4d3fc2e81d786d5cbdbb13d1e9b2fe97416210328028c9dda33a0df74c5580f4 /bin/sh

# 进入容器里后，执行启用web界面管理插件命令
rabbitmq-plugins enable rabbitmq_management

成功启动UI界面管理插件，如图：

测试链接：http://localhost:15672/#/ ，默认账户密码：guest / guest

-----------至此单节点RabbitMQ服务安装完毕-----------

二、开始集群部署

准备工作

1、启动多个RabbitMQ

用上面的步骤，重新run两个镜像。注意：
（1）多容器节点之间使用“–link”参数去关联其它rabbitmq的节点，
语法：–link 容器名:hostname。
（2）Erlang Cookie值必须相同，也就是RABBITMQ_ERLANG_COOKIE参数的值必须相同。

# 查看rabbitmq镜像在docker中的ID（a6b922761c18为rabbitmq的镜像ID）
docker images | grep rabbitmq

# 启动rabbitmq-2节点
docker run -d --name rabbitmq-2 -p 5673:5672 -p 15673:15672 --link rabbitmq-1:rabbitmq-1 --hostname rabbitmq-2 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' a6b922761c18

# 查看rabbitmq-2节点的运行状态
docker ps | grep rabbitmq-2

# 启动rabbitmq-3节点
docker run -d --name rabbitmq-3 -p 5674:5672 -p 15674:15672 --link rabbitmq-1:rabbitmq-1 --link rabbitmq-2:rabbitmq-2 --hostname rabbitmq-3 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' a6b922761c18
# 查看rabbitmq-3节点的运行状态
docker ps | grep rabbitmq-3

2、访问测试

http://localhost:15673/#/

http://localhost:15674/#/

3、检查.erlang.cookie是否相同

有些特殊的情况，比如已经运行了一段时间的几个单个物理机，我们在之前没有设置过相同的Erlang Cookie值，现在我们要把单个的物理机部署成集群，我们需要同步Erlang的Cookie值。

为什么要配置相同的erlang cookie？
因为RabbitMQ是用Erlang实现的，Erlang Cookie相当于不同节点之间相互通讯的秘钥，Erlang节点通过交换Erlang Cookie获得认证。

Erlang Cookie的位置
要想知道Erlang Cookie位置，首先要取得RabbitMQ启动日志里面的home dir路径，作为根路径。使用：“docker logs 容器名称”查看rabbitmq启动日志，如下图，可知rabbitmq的根目录是：/var/lib/rabbitmq/，所以Erlang Cookie的全部路径就是 “/var/lib/rabbitmq/.erlang.cookie”

复制Erlang Cookie到其他RabbitMQ节点
获取到第一个RabbitMQ的Erlang Cookie之后，只需要把这个文件复制到其他RabbitMQ节点即可。
物理机和容器之间复制命令如下：
容器复制文件到物理机：docker cp 容器名称:容器目录 物理机目录
物理机复制文件到容器：docker cp 物理机目录 容器名称:容器目录

docker exec -it rabbitmq-1 /bin/bash
more /var/lib/rabbitmq/.erlang.cookie 
或 
cat $HOME/.erlang.cookie
----exit----(得到结果：FROBKQGAXELASVUYHSXL)

docker exec -it rabbitmq-2 /bin/bash
more /var/lib/rabbitmq/.erlang.cookie
----exit----(得到结果：UMMUDLAWCOFDJPMROLCZ)

docker exec -it rabbitmq-3 /bin/bash
more /var/lib/rabbitmq/.erlang.cookie
----exit----(得到结果：UHWFHBVBACBMGYNKEQHR)

可知，跟我们启动RabbitMQ服务时设置的cookie值不一样（设置的是‘rabbitcookie’），这也验证了3.8.3以上的版本不推荐使用RABBITMQ_ERLANG_COOKIE这个配置项来配置cookie的值。

4、手动把.erlang.cookie的值改成一致

统一把.erlang.cookie文件值都改成rabbitmq-1节点的值，我们直接复制文件到另外两个节点即可：

如果你的rabbitmq节点docker容器里没有.erlang.cookie文件或者文件值为空，可以如下处理（docker容器一般无法直接使用vi|vim）：
# 把docker容器上的文件复制到物理机
docker cp rabbitmq-1:/var/lib/rabbitmq/.erlang.cookie /Users/yuanjiabo/work
# 修改文件值后，把物理机上的文件复制到docker容器
docker cp /Users/yuanjiabo/work/.erlang.cookie rabbitmq-1:/var/lib/rabbitmq/

# 复制.erlang.cookie文件到另外两个rabbitmq节点：
注意，下面这样跨容器直接cp是不允许的，所以需要挨个从物理机上传到docker容器
➜  ~ docker cp rabbitmq-1:/var/lib/rabbitmq/.erlang.cookie rabbitmq-2:/var/lib/rabbitmq/
copying between containers is not supported

# 把物理机上的.erlang.cookie文件复制到rabbitmq-2对应的docker容器里
docker cp /Users/yuanjiabo/work/.erlang.cookie rabbitmq-2:/var/lib/rabbitmq/

# 把物理机上的.erlang.cookie文件复制到rabbitmq-3对应的docker容器里
docker cp /Users/yuanjiabo/work/.erlang.cookie rabbitmq-3:/var/lib/rabbitmq/

# 设置.erlang.cookie文件的权限:
chmod 600 /var/lib/rabbitmq/.erlang.cookie
# 把.erlang.cookie文件的拥有者改为指定的rabbitmq用户或组
chown -R rabbitmq:rabbitmq .erlang.cookie

启动独立节点

集群是通过将现有的RabbitMQ节点重新配置为集群来设置的。因此第一步是以正常方式在所有节点上启动RabbitMQ：

#在rabbitmq-1
docker exec -it rabbitmq-1 /bin/bash
rabbitmq-server -detached

#在rabbitmq-2
docker exec -it rabbitmq-2 /bin/bash
rabbitmq-server -detached

#在rabbitmq-3
docker exec -it rabbitmq-3 /bin/bash
rabbitmq-server -detached

创建三个独立的RabbitMQ代理，每个节点一个，用cluster_status命令确认：

#在rabbitmq-1
rabbitmqctl cluster_status
Cluster status of node rabbit@rabbitmq-1 ...
Cluster name: rabbit@rabbitmq-1
Disk Nodes rabbit@rabbitmq-1
Running Nodes rabbit@rabbitmq-1

#在rabbitmq-2
rabbitmqctl cluster_status

#在rabbitmq-3
rabbitmqctl cluster_status

创建集群

为了连接集群中的三个节点，我们告诉另外两个节点，比如rabbit@rabbitmq-2和 rabbit@rabbitmq-3，加入第三个节点的集群，比如rabbit@rabbitmq-1。在此之前，必须重新设置两个新加入的成员节点。

我们首先将rabbit@rabbitmq-2加入一个带有rabbit@rabbitmq-1的集群中：
为此，在rabbit@rabbitmq-2上，我们停止RabbitMQ应用程序并加入rabbit@rabbitmq-1集群，然后重新启动rabbit@rabbitmq-2节点的RabbitMQ应用程序。请注意，节点必须先重置，然后才能加入现有集群。重置节点会删除该节点上存在的所有资源和数据。这意味着节点不能成为集群的成员并同时保留其现有数据。如果需要，请提前进行备份和恢复。

#在rabbitmq-2
rabbitmqctl stop_app
# => Stopping rabbit application on node rabbit@rabbitmq-2 ...

rabbitmqctl reset
# => Resetting node rabbit@rabbitmq-2 ...

rabbitmqctl join_cluster --ram rabbit@rabbitmq-1
# => Clustering node rabbit@rabbitmq-2 with rabbit@rabbit-1

rabbitmqctl start_app
# => Starting node rabbit@rabbitmq-2 ...

rabbitmqctl cluster_status
#=> Cluster status of node rabbit@rabbitmq-2 ...

Basics Cluster name: rabbit@rabbitmq-2
Disk Nodes rabbit@rabbitmq-1
RAM Nodes rabbit@rabbitmq-2

Running Nodes
rabbit@rabbitmq-1
rabbit@rabbitmq-2

现在我们将rabbit@rabbitmq-3加入同一个集群。步骤和上面一样，只是这次我们将集群到rabbitmq-2来证明选择集群的节点无关紧要，只要提供一个在线节点就足够了，节点将被集群到指定节点所属。

# 在rabbitmq-3
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster --ram rabbit@rabbitmq-2
rabbitmqctl start_app

通过在任意节点上运行cluster_status命令，我们可以看到这三个节点加入了一个集群：
# 在rabbitmq-3
rabbitmqctl cluster_status

按照上述步骤，我们可以在集群运行时随时向集群添加新节点。

扩展：
在集群中新增加节点
（1）新节点单机安装rabbitmq
（2）在集群已有节点增加hosts：在集群已有的节点中逐个修改节点中的/etc/hosts文件，添加新节点的IP地址与hostname的映射关系。配置/etc/hosts文件是保证集群中的任意两个节点之间能够通过hostname实现ping通。
（3）新节点启动服务
（4）新节点关闭并重置application：
./rabbitmqctl stop_app
./rabbitmqctl reset
（5）新节点添加到集群：
在新的节点中，执行将rabbitmq添加到已有集群中命令：
磁盘节点执行命令：./rabbitmqctl join_cluster rabbit@
默认添加的就是磁盘节点。@后面为启动的第一个磁盘节点名称。
内存节点执行命令：./rabbitmqctl join_cluster --ram rabbit@xxx
–ram表示磁盘节点。@后面为启动的第一个磁盘节点名称。
（6）新节点开启application：./rabbitmqctl start_app
（7）命令查看集群，在任意一节点上执行命令：./rabbitmqctl cluster_status
（8）Web控制台查看集群
（9）集群中queue消息数据同步
默认集群中已有的queue消息数据不会自动同步到新增加的节点中，需要在web控制台中手动进行同步消息数据。待同步的消息数据：

手动执行同步消息数据按钮：

也可以到对应节点上通过rabbitmqctl命令同步：
root@rabbitmq-3:/# rabbitmqctl sync_queue ORIGIN_QUEUE
Synchronising queue ‘GP_FIRST_QUEUE’ in vhost ‘/’ …
2、减少节点
在主节点上，执行解除与指定节点的cluster关系的命令即可。
执行命令：./rabbitmqctl forget_cluster_node rabbit@xxx
说明：@前面为固定写法，@后面为要移出的节点名称。
移除前，把需要移除的节点数据备份好，关闭并重置服务。

重启集群节点

已加入集群的节点可以随时停止。它们也可能失败或被操作系统终止。
一般来说，如果一个节点停止后大部分节点仍然在线，这不会影响集群的其余部分，尽管集群的客户端连接分布、队列副本放置和负载分布会发生变化。

来自在线对等点(peer)的模式同步

重新启动的节点将在启动时从其对等方同步模式和其他信息。在此过程完成之前，节点不会完全启动并正常运行。

因此，了解进程节点在停止和重新启动时经历的过程非常重要。

停止节点选择一个在线集群成员（只考虑磁盘节点）在重启后同步。重启后，默认情况下，节点将尝试联系该对等方 10 次，响应超时为 30 秒。

如果对等点在该时间间隔内可用，则节点成功启动，从对等点同步所需的内容并继续运行。

如果对等点不可用，则重新启动的节点将放弃并自动停止。这种情况可以通过日志中的超时（timeout_waiting_for_tables）警告消息来识别，最终导致节点启动失败：

2021-10-15 21:10:51.361 [警告] <0.269.0> 等待 Mnesia 表时出错：{timeout_waiting_for_tables,[rabbit@node2,rabbit@node1],[rabbit_durable_queue]}
2021-10-15 21:10:51.361 [info] <0.269.0>等待等待表30000毫秒，还剩1次重试
2021-10-15 21:11:21.362 [警告] <0.269.0> 等待 Mnesia 表时出错：{timeout_waiting_for_tables,[rabbit@node2,rabbit@node1],[rabbit_durable_queue]}
2021-10-15 21:11:21.362 [info] <0.269.0>等待等待表30000毫秒，还剩0次重试

当一个节点在关闭期间没有在线对等点时，它将在不尝试与任何已知对等点同步的情况下启动。但是，它不是作为独立节点启动的，对等节点将能够重新加入它。

因此，当整个集群关闭时，最后一个关闭的节点是唯一一个在关闭时没有任何正在运行的对等节点。该节点可以在不联系任何对等方的情况下启动。由于节点将尝试联系已知对等方长达 5 分钟（默认情况下），因此可以在该时间段内以任何顺序重新启动节点。在这种情况下，他们将成功地一一重聚。可以使用两个配置设置来调整此时间窗口：

#等待60秒而不是30秒
mnesia_table_loading_retry_timeout = 60000

#重试15次而不是10次
mnesia_table_loading_retry_limit = 15

通过调整这些设置并调整已知对等点必须返回的时间窗口，可以解决可能需要 5 分钟以上才能完成的集群范围重新部署方案的场景。

重新启动之间的主机名更改

如果节点名称或主机名称更改后重新加入的节点的数据目录路径因此更改，则该节点可以作为空白节点开始。此类节点将无法重新加入集群。当节点离线时，它的对等节点可以被重置或使用空白数据目录启动。在这种情况下，恢复节点也将无法重新加入其对等节点，因为内部数据存储集群身份将不再匹配。

考虑以下场景：

有A、B、C 3个节点的集群
节点 A 关闭
节点 B 被重置
节点 A 启动
节点 A 尝试重新加入 B，但 B 的集群标识已更改，所以节点 B 无法将节点 A 识别为已知的集群成员，因为它已被重置。
在这种情况下，节点 B 将拒绝来自 A 的集群尝试，并在日志中显示适当的错误消息：
Node 'rabbit@rabbitmq-1' thinks it's clustered with node 'rabbit@rabbitmq-2', but 'rabbit@rabbitmq-2' disagrees

在这种情况下，B 可以再次重置，然后才能加入 A，或者 A 可以重置并成功加入 B。

集群节点重启示例

下面的示例使用 CLI 工具关闭节点rabbit@rabbitmq-1和 rabbit@rabbitmq-3并在每一步操作都检查下集群状态：

# 在rabbitmq-1
rabbitmqctl stop

# 在rabbitmq-2
rabbitmqctl cluster_status

# 在rabbitmq-3
rabbitmqctl cluster_status

# 在rabbitmq-3
rabbitmqctl stop

# 在rabbitmq-2
rabbitmqctl cluster_status

节点重新启动，继续检查集群状态：

# 在rabbitmq-1
rabbitmq-server -detached
rabbitmqctl cluster_status

# 在rabbitmq-2
rabbitmqctl cluster_status

# 在rabbitmq-3
rabbitmq-server -detached

# 在rabbitmq-1
rabbitmqctl cluster_status
# 在rabbitmq-2
rabbitmqctl cluster_status
# 在rabbitmq-3
rabbitmqctl cluster_status

在对等点不可用的情况下强制节点启动

在某些情况下，最后一个脱机的节点无法恢复。可以使用forget_cluster_node rabbitmqctl命令从集群中删除它。

拆分集群

有时需要从集群中删除节点。必须使用rabbitmqctl命令显式执行此操作 。
如从集群中移除rabbit@rabbitmq-3，将其返回到独立运行的节点。为此，在rabbit@rabbitmq-3 上，我们停止RabbitMQ应用程序，重置节点，然后重新启动 RabbitMQ 应用程序。

# 在rabbitmq-3
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app

在节点上运行cluster_status命令确认rabbit@rabbitmq-3现在不再是集群的一部分并独立运行：
#在rabbitmq-1
rabbitmqctl cluster_status

# 在rabbitmq-2
rabbitmqctl cluster_status

# 在rabbitmq-3
rabbitmqctl cluster_status

我们还可以远程删除节点。例如，当必须处理无响应的节点时，这很有用。

# 在rabbitmq-1
rabbitmqctl stop_app

# 在rabbitmq-2
rabbitmqctl forget_cluster_node rabbit@rabbitmq-1
# => 从集群中删除节点 rabbit@rabbitmq-1 ... 

请注意，rabbitmq-1仍然认为它与rabbitmq-2聚集在一起 ，并且尝试启动它会导致错误。我们需要重置它才能再次启动它。

# 在rabbitmq-1
rabbitmqctl start_app
# => 启动节点 rabbit@rabbitmq-1 ... 
# => 错误：consistent_cluster：节点 rabbit@rabbitmq-1 认为它与节点 rabbit@rabbitmq-2 聚在一起，但 rabbit@rabbitma-2 不同意

rabbitmqctl reset
# => 重置节点 rabbit@rabbitmq-1 ...完成。

rabbitmqctl start_app
# => 开始节点 rabbit@rabbitmq-1 ... 

该cluster_status命令现在显示为独立的RabbitMQ工作的所有三个节点：

# 在rabbitmq-1
rabbitmqctl cluster_status

# 在rabbitmq-2
rabbitmqctl cluster_status

# 在rabbitmq-3
rabbitmqctl cluster_status

注意rabbit@rabbitmq-2保留了集群的剩余状态，而rabbit@rabbitmq-1 和rabbit@rabbitmq-3是刚初始化的 RabbitMQ brokers。如果我们想重新初始化 rabbit@rabbitmq-2，我们遵循与其他节点相同的步骤：

# 在rabbitmq-2
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app

如何重置节点

有时可能需要重置节点（擦除其所有数据），然后使其重新加入集群。一般来说，有两种可能的情况：当节点正在运行时，以及当节点无法启动或不会响应 CLI 工具命令时。
重置节点将删除其所有数据、集群成员信息、配置的运行时参数、用户、虚拟主机和任何其他节点数据。它还将从其集群中永久删除该节点。

要重置正在运行的响应节点，首先使用rabbitmqctl stop_app停止RabbitMQ ，然后使用rabbitmqctl reset重置它：

# 在rabbitmq-1
rabbitmqctl stop_app
rabbitmqctl reset

如果节点无响应，则首先必须使用任何手段将其停止。对于无法启动的节点，情况已经如此。然后覆盖节点的数据目录位置或[重新]移动现有数据存储。这将使节点作为一个空白节点开始。必须指示它重新加入其原始集群（如果有）。
已重置并重新加入其原始集群的节点将同步所有虚拟主机、用户、权限和拓扑（队列、交换、绑定）、运行时参数和策略。 如果将选择节点来托管副本，则仲裁队列内容将被复制。重置节点上的非复制队列内容将丢失。

升级集群

可以在升级指南中找到升级集群 的说明。

主机名更改

RabbitMQ节点使用主机名相互通信。因此，所有节点名称必须能够解析所有集群对等体的名称。对于诸如rabbitmqctl之类的工具也是如此。

除此之外，默认情况下RabbitMQ使用系统的当前主机名命名数据库目录。如果主机名更改，则会创建一个新的空数据库。为避免数据丢失，设置固定且可解析的主机名至关重要。

每当主机名更改时，RabbitMQ节点必须重新启动。

使用rabbit@localhost 作为代理节点名可以达到类似的效果。此解决方案的影响是群集将不起作用，因为所选主机名将无法解析为来自远程主机的可路由地址。当从远程主机调用时，rabbitmqctl命令同样会失败。不受此弱点影响的更复杂的解决方案是使用 DNS。如果您想使用完整主机名作为您的节点名（RabbitMQ 默认为短名称），并且该完整主机名可使用 DNS 解析，您可能需要调查设置环境变量 RABBITMQ_USE_LONGNAME=true。
详情请参阅有关主机名解析的部分。

跨集群的 Erlang 版本

强烈建议集群中的所有节点运行相同的 Erlang版本。

从客户端连接到集群

客户端可以正常连接到集群中的任何节点。如果该节点出现故障，而集群的其余部分仍然存在，那么客户端应该注意到关闭的连接，并且应该能够重新连接到集群中某个幸存的成员。

许多客户端支持在连接时按顺序尝试的主机名列表。

通常不建议将 IP 地址硬编码到客户端应用程序中：这会导致不灵活，并且如果集群配置或集群中的节点数量发生变化，则需要编辑、重新编译和重新部署客户端应用程序。

磁盘节点和RAM节点

节点可以是磁盘节点或RAM节点。RAM节点仅在RAM中存储内部数据库表。这不包括消息、消息存储索引、队列索引和其他节点状态。

在绝大多数情况下，您希望所有节点都是磁盘节点；RAM节点是一种特殊情况，可用于提高具有高队列、交换或绑定流失的集群的性能。RAM节点不提供更高的消息速率。如有疑问，请仅使用磁盘节点。

由于RAM节点仅在RAM中存储内部数据库表，因此它们必须在启动时从对等节点同步它们。这意味着一个集群必须至少包含一个磁盘节点。因此，无法手动删除集群中最后一个剩余的磁盘节点。

具有RAM节点的集群

RAM节点仅将其元数据保存在内存中。由于 RAM 节点不像磁盘节点那样多地写入磁盘，因此它们可以表现得更好。但是，请注意，由于持久队列数据始终存储在磁盘上，因此性能改进只会影响资源管理（例如添加/删除队列、交换或虚拟主机），而不会影响发布或消耗速度。

RAM节点是一个高级用例。我们在设置第一个集群时不应该使用RAM节点。我们应该有足够的磁盘节点来处理冗余需求，然后在必要时添加额外的 RAM 节点以进行扩展。

仅包含RAM节点的集群也会不太稳定：如果集群停止，将无法再次启动它并且会丢失所有数据。RabbitMQ会在很多情况下阻止创建仅 RAM 节点的集群，但它不能绝对阻止它。

为简单起见，此处的示例显示了一个包含一个磁盘和一个RAM节点的集群；这样的集群是一个糟糕的设计选择。

创建 RAM 节点

我们可以在节点首次加入集群时将其声明为RAM节点。我们像以前一样使用rabbitmqctl join_cluster来执行此 操作，但传递 --ram标志：

# 在rabbitmq-2
rabbitmqctl stop_app
rabbitmqctl join_cluster --ram rabbit@rabbitmq-1
rabbitmqctl start_app

RAM 节点在集群状态中显示如下：

# 在rabbitmq-1
rabbitmqctl cluster_status

# 在rabbitmq-2
rabbitmqctl cluster_status

更改节点类型
我们可以将节点的类型从 ram 更改为 disc，反之亦然。假设我们想要反转rabbit@rabbitmq-2和rabbit@rabbitmq-1的类型 ，将前者从 ram 节点转换为磁盘节点，将后者从磁盘节点转换为 ram 节点。为此，我们可以使用 change_cluster_node_type命令。必须先停止节点。

# 在rabbitmq-2
rabbitmqctl stop_app
rabbitmqctl change_cluster_node_type disc
# => 将 rabbit@rabbitmq-2 变成一个磁盘节点 ...完成。
rabbitmqctl start_app

# 在rabbitmq-1
rabbitmqctl stop_app
rabbitmqctl change_cluster_node_type ram
# => 将 rabbit@rabbitmq-1 变成 ram 节点 ...完成。
rabbitmqctl start_app

创建rabbitmq策略

Pattern:匹配的规则，如果是匹配所有的队列，那就是^
Definition:使用ha-mode模式中的all，也就是同步所有匹配的队列

破坏性测试

从rabbitmq管理控制台往队列test_queue里发布一条消息


1 停掉rabbimq-1，rabbitmq-2和rabbitmq-3消息依然存在
2 继续停掉 rabbimq-2，查看rabbitmq-3消息依然存在


3 恢复rabbitmq-1和rabbitmq-2




从中可以看到test_queue队列后面+2变成了红色，鼠标指上去显示镜像无法同步。如果这时候停掉rabbitmq-3节点的服务，那么队列里面的消息将会丢失。
采取的解决办法是选择在rabbitmq-1或者rabbitmq-2节点上执行同步命令即可恢复：

root@rabbitmq-2:/# rabbitmqctl sync_queue test_queue
Synchronising queue 'test_queue' in vhost '/' ...
root@rabbitmq-2:/#