How does ActiveMQ implement high availability using Master-Slave?

Traditional Master-Slave HA in ActiveMQ Classic relies on an exclusive lock on a shared persistence store, either a shared-filesystem KahaDB lock file or a shared JDBC database, to guarantee only one broker instance actively serves clients at a time.

Multiple broker processes start up pointing at the same store; the first one to acquire the exclusive lock becomes master and starts accepting connections, while the others block waiting for the lock, acting as passive slaves that hold no client connections. If the master crashes or shuts down, its lock is released, and one of the waiting slaves acquires it and takes over as the new master. Because they share the same underlying store, the new master resumes with exactly the messages and state the failed master last persisted, without needing to synchronously replicate anything itself - the storage layer handles consistency. Clients configure a failover: transport URL listing all broker addresses so they automatically reconnect to whichever instance is currently master after a failover event.

A practical detail worth knowing: because failover relies on releasing and re-acquiring a lock on shared storage, the failover window isn't instantaneous - there's a brief gap between the master disappearing and a slave detecting the released lock, during which in-flight requests may need to be retried by the client once reconnected. This lock-based design also means the shared store itself, whether a filesystem or database, becomes the single point of failure the whole HA scheme depends on, which is why that store is usually put on its own redundant storage, like a SAN or replicated filesystem, rather than a single disk.