主要故障¶
如果主服务器松开独占锁，则它会立即关闭。如果一个主服务器关闭或发生故障，另一个副本将获得锁，因此拓扑将切换到下图
其中一个复制副本立即获取文件系统上的独占锁，开始成为主复制副本，启动其所有传输连接器。客户端断开与已停止的主代理的连接，然后故障转移传输尝试连接到可用的代理-其中唯一可用的代理是新的主代理。
共享文件系统主/副本¶
基本上，您可以从同一个共享文件系统目录运行任意多个代理。第一个获取文件独占锁的代理是主代理。如果该代理死亡并释放锁，则另一个代理将接管。副本代理坐在一个循环中，试图从主代理获取锁。以下示例显示如何为共享文件系统主/副本配置代理，其中/sharedFileSystem是共享文件系统上的某个目录。这只是将基于文件的存储配置为使用共享目录的一种情况。
<persistenceAdapter>
<kahaDB directory="/sharedFileSystem/sharedBrokerData"/>
</persistenceAdapter>
或：
<persistenceAdapter>
<levelDB directory="/sharedFileSystem/sharedBrokerData"/>
</persistenceAdapter>
或：
<persistenceAdapter>
<amqPersistenceAdapter directory="/sharedFileSystem/sharedBrokerData"/>
</persistenceAdapter>
启动¶
启动时，一个主代理获取代理文件目录上的独占锁-所有其他代理都是副本，并暂停等待独占锁。
客户端应该使用故障转移传输连接到可用代理。例如，使用类似以下的URL
failover:(tcp://broker1:61616,tcp://broker2:61616,tcp://broker3:61616)
只有主代理启动其传输连接器，因此客户端只能连接到主代理。
主要重启¶
您可以随时重新启动加入群集的其他代理，并在主代理关闭或发生故障时作为副本启动，以等待成为主代理。主拓扑是在旧的So重新启动后创建的。。。
备注
如果您有一个SAN或共享文件系统，它可以用来提供高可用性，这样，如果一个代理被杀死，另一个代理可以立即接管。
确保共享文件锁定正常工作
请注意，此故障转移系统的要求是像SAN这样的分布式文件系统，独占文件锁可以可靠地工作。如果您没有这样一个可用的东西，那么考虑使用Primary/Replica，它实现了类似的功能，但是使用本地文件系统（ActiveMQ执行复制）在普通硬件上工作。
OCFS2警告
正在使用OCFS2进行测试，两个代理都认为他们拥有主锁-这是因为“OCFS2只支持使用'fcntl'锁定，而不支持'lockf and flock'，因此不支持来自Java的互斥文件锁定。”
从http://sources.redhat.com/cluster/faq.html gfs_vs_ocfs2：
OCFS2:没有集群感知的flock或posix锁
gfs：完全支持集群范围的集群和posix锁，并得到支持。
NFSV3警告
在NFSv3客户端异常终止（即ActiveMQ主代理）的情况下，NFSv3服务器将不会超时该客户端所持有的锁。这有效地使ActiveMQ数据目录不可访问，因为ActiveMQ副本代理无法获取锁，因此无法启动。NFSv3解决这一困境的唯一方法是重新启动所有ActiveMQ实例以重置所有内容。
NFSV4的使用是另一种解决方案，因为它的设计包括锁的超时。当使用NFSv4时，持有锁的客户机遇到异常终止，根据设计，锁在30秒后释放，允许另一个客户机获取锁。有关此的详细信息，请参阅此日志。