ActiveMQ MySQL共享JDBC主从架构下固定指定Broker为Master的方案

结论先行：原生共享JDBC模式的ActiveMQ主从集群没有内置固定主节点的配置，默认选主完全基于MySQL中ACTIVEMQ_LOCK表的排他锁抢占，谁先拿到锁谁就提供服务，不存在节点优先级规则。但可以通过低侵入配置或者简单管控脚本，实现原Master恢复后优先接管集群的需求。

原生机制核心逻辑 #

所有Broker节点启动时都会尝试获取持久化锁表的排他行锁，拿到锁的节点成为Master对外服务，其余节点作为Slave阻塞等待锁释放，整个选主过程没有权重、优先级判定，因此默认情况下原Master故障恢复后，会和其他Slave一样排队等锁，必须等当前Master释放锁才能接管。

可落地实现方案 #

方案1：配置调优实现主节点优先抢占（生产环境推荐，无代码侵入） #

不需要修改源码，只需要给不同角色的节点配置差异化的锁竞争参数，让指定的固定Master节点抢锁的优先级远高于Slave节点即可：

• 固定Master节点的activemq.xml中，修改JDBC持久化适配器配置：

<persistenceAdapter>
    <jdbcPersistenceAdapter 
        dataSource="#your-mysql-datasource"
        lockKeepAlivePeriod="1000" 
        lockAcquireSleepInterval="1000"
    />
</persistenceAdapter>

参数说明：lockKeepAlivePeriod设为1000ms，即Master每1秒给锁做一次续期；lockAcquireSleepInterval设为1000ms，即抢锁失败时每1秒重试一次。

• 所有Slave节点的同位置配置，调大锁重试和续期间隔：

<persistenceAdapter>
    <jdbcPersistenceAdapter 
        dataSource="#your-mysql-datasource"
        lockKeepAlivePeriod="5000" 
        lockAcquireSleepInterval="30000"
    />
</persistenceAdapter>

同时给Slave节点加30秒的启动延迟，避免Slave启动时比Master先抢到锁，可以在启动脚本中添加JVM参数实现：
ACTIVEMQ_OPTS="$ACTIVEMQ_OPTS -Dactivemq.startup.delay=30000"

• 实际效果：原Master故障恢复启动后，会以1秒一次的频率尝试抢锁。当前接管服务的Slave作为临时Master时，锁续期间隔是5秒，只要它出现GC停顿、网络闪断等任何导致锁续期失败的情况，原Master会立刻抢到锁接管服务，整个切换过程通常在2秒内，客户端配合failover协议完全无感知。

注意：这个方案不会在原Master启动瞬间强制踢掉正在运行的临时Master，这是共享存储架构的安全设计——如果强制中断正在运行的Master，可能导致未刷盘的消息丢失、事务状态不一致。这个方案已经是无代码修改场景下，最接近固定主效果的实现，生产环境用的最多。

方案2：外部管控脚本实现强制主回切 #

如果要求原Master恢复后必须立刻接管服务，可以通过外部脚本实现可控切换：

• 给固定Master节点部署检测脚本，持续检测节点进程状态、数据库连通性、启动完成状态。
• 当检测到原Master已经正常启动、可以正常连接MySQL时，通过Jolokia接口调用当前临时Master（原Slave）的优雅停机接口，让它主动释放数据库锁。
• 锁释放后等待中的原Master会立刻拿到锁成为Master，此时脚本再自动拉起之前停机的Slave节点，让它重新回到备机等待状态。
• 注意点：绝对不能用kill -9强杀临时Master进程，否则会导致MySQL中的锁记录残留，需要手动清空ACTIVEMQ_LOCK表才能恢复集群。

不推荐的做法 #

不要为了实现强制固定主去修改ActiveMQ源码，给锁抢占逻辑加节点优先级。共享JDBC主从的设计初衷就是无优先级的故障转移，如果强行让不稳定的原Master反复抢锁回切，会导致集群频繁主从切换，反而大幅降低可用性。

内容的提问来源于stack exchange，提问作者Areej Fatimah