In a non-automated use-case I'd recommend an administrator take a look at each of the brokers' log files to see which one had been active most recently and then restart that broker first (and if that server happened to be a slave its configuration would need to be changed to be a master so it would fully start rather than just wait for its corresponding master). If your environment is automated then you'll have to develop some kind of process to approximate what an administrator would do.
That said, in a fully automated environment a master/slave pair may not make much sense. Presumably the automation could simply restart the master broker when it dies and clients can simply reconnect. Combined with a redundant, robust file store this is a viable solution for high availability. Justin On Thu, May 30, 2019 at 5:41 AM Bummer <jen...@centrum.cz> wrote: > /One issue to be aware of is: in case of a successful fail-over, the > backup's > data will be newer than the one at the live's storage. If you configure > your > live server to perform a failback to live server when restarted, it will > synchronize its data with the backup's. If both servers are shutdown, the > administrator will have to determine which one has the latest data./ > Source > < > https://activemq.apache.org/components/artemis/documentation/latest/ha.html> > > > How do I overcome this in an automated environment without having a full > control over server restarts? > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
