> server.lock becomes the new timestamp when backup takes over. If the backup is activating that indicates the primary lost the file lock on server.lock without realizing it (which is a potential issue on NFS). When the backup activates it updates the timestamp of server.lock and when the primary sees that the timestamp has been updated it realizes that it has lost the lock and shuts itself down.
> The move of the NFS service to the other site should be uninterrupted for the server and their mounts. Based on the evidence it appears something is happening to the file lock on server.lock during this "move" process. > With "warm standby" I expect, the primary releases the queue to the backup, without terminating the process. The broker doesn't have such a feature since it is customarily run as a "service" which will be automatically restarted by the platform in the case of a failure like this. This platform functionality saves the broker from having to implement such a feature. Justin On Fri, Mar 7, 2025 at 1:10 AM Felix Buergler (Suva) <felix.buerg...@suva.ch.invalid> wrote: > Hi Justin, > > server.lock becomes the new timestamp when backup takes over. The move of > the NFS service to the other site should be uninterrupted for the server > and their mounts. > With "warm standby" I expect, the primary releases the queue to the > backup, without terminating the process. So the primary would be able to > take his primary role again, when backup fails. > > Regards, Felix > > -----Ursprüngliche Nachricht----- > Von: Justin Bertram <jbert...@apache.org> > Gesendet: Donnerstag, 6. März 2025 17:15 > An: users@activemq.apache.org > Betreff: Re: AMQ 2.39.0 - shared-storage Failover > > > > ACHTUNG: Diese Nachricht kommt von extern. Seien Sie kritisch beim > Öffnen von Links und Anhängen. > > > > > > When NFS Share is moved online to the other site... > > Are you saying that when this happens the timestamp of the server.lock > file is updated causing the primary broker to shut itself down? If so, that > seems to be a problem with whatever is updating the timestamp of the > server.lock file. The broker monitors the server.lock file to ensure that > no other brokers (e.g. the backup) are running using this same journal. > When the timestamp of the server.lock file is update that signals to the > active broker that it has lost the lock and should shut itself down. > > > Is there a way to remain Primary “warm standby” without terminating > > the > process and failback to Primary? > > Can you elaborate on what specifically you mean by "warm standby"? > > > Justin > > On Thu, Mar 6, 2025 at 1:36 AM Felix Buergler (Suva) < > felix.buerg...@suva.ch.invalid> wrote: > > > Hi all, > > > > > > > > We run AMQ 2.39.0 with NFS shared-store ha-policy. > > > > NFS Service is based on Hitachi HNAS Cluster. When NFS Share is moved > > online to the other site, our AMQ Backup takes over and Primary is > > terminating. > > > > > > > > Is there a way to remain Primary “warm standby” without terminating > > the process and failback to Primary? > > > > Or even better, not to loose the primary Role, when > > /nfsfpamb/amqt01/data/journal/server.lock > > get’s a new timestamp. > > > > > > > > Primary: > > > > <name>amq-snbx-intranet</name> > > > > <persistence-enabled>true</persistence-enabled> > > > > > > > > <ha-policy> > > > > <shared-store> > > > > <primary> > > > > <failover-on-shutdown>true</failover-on-shutdown> > > > > </primary> > > > > </shared-store> > > > > </ha-policy> > > > > > > > > <!-- Resource-Manager transaction-timeout 12min, wegen 10min > > tx-timeout pdf-server --> > > > > <transaction-timeout>1800000</transaction-timeout> > > > > > > > > <!-- Connectors --> > > > > > > > > <connectors> > > > > <connector > > name="netty-connector">tcp://node1:63616</connector> > > > > <connector > > name="netty-backup-connector">tcp://node2:63616</connector> > > > > </connectors> > > > > > > > > <!-- Acceptors --> > > > > <acceptors> > > > > <acceptor > > name="netty-acceptor">tcp://node1:63616?amqpMinLargeMessageSize=512000 > > </acceptor> > > > > </acceptors> > > > > > > > > <cluster-connections> > > > > <cluster-connection name="amq-snbx-intranet"> > > > > <connector-ref>netty-connector</connector-ref> > > > > <static-connectors> > > > > <connector-ref>netty-backup-connector</connector-ref> > > > > </static-connectors> > > > > </cluster-connection> > > > > </cluster-connections> > > > > > > > > > > > > > > > > > > > > Backup: > > > > <name>amq-snbx-intranet</name> > > > > <persistence-enabled>true</persistence-enabled> > > > > > > > > <ha-policy> > > > > <shared-store> > > > > <backup> > > > > <allow-failback>true</allow-failback> > > > > </backup> > > > > </shared-store> > > > > </ha-policy> > > > > > > > > <!-- Resource-Manager transaction-timeout 12min, wegen 10min > > tx-timeout pdf-server --> > > > > <transaction-timeout>1800000</transaction-timeout> > > > > > > > > <!-- Connectors --> > > > > > > > > <connectors> > > > > <connector > > name="netty-live-connector">tcp://node1:63616</connector> > > > > <connector > > name="netty-connector">tcp://node2:63616</connector> > > > > </connectors> > > > > > > > > <!-- Acceptors --> > > > > <acceptors> > > > > <acceptor > > name="netty-acceptor">tcp://node2:63616?amqpMinLargeMessageSize=512000 > > </acceptor> > > > > </acceptors> > > > > > > > > <cluster-connections> > > > > <cluster-connection name="amq-snbx-intranet"> > > > > <connector-ref>netty-connector</connector-ref> > > > > <static-connectors> > > > > <connector-ref>netty-live-connector</connector-ref> > > > > </static-connectors> > > > > </cluster-connection> > > > > </cluster-connections> > > > > > > > > Regards, Felix > > > > ------------------------------ > > > > Disclaimer: > > > > Diese Nachricht und ihr eventuell angehängte Dateien sind nur für den > > Adressaten bestimmt. Sie kann vertrauliche oder gesetzlich geschützte > > Daten oder Informationen beinhalten. Falls Sie diese Nachricht > > irrtümlich erreicht hat, bitten wir Sie höflich, diese unter > > Ausschluss jeglicher Reproduktion zu löschen und die absendende Person > > zu benachrichtigen. Danke für Ihre Hilfe. > > > > This message and any attached files are for the sole use of the > > recipient named above. It may contain confidential or legally > > protected data or information. If you have received this message in > > error, please delete it without making any copies whatsoever and > > notify the sender. Thank you for your assistance. > > > > ________________________________ > > Disclaimer: > > Diese Nachricht und ihr eventuell angehängte Dateien sind nur für den > Adressaten bestimmt. Sie kann vertrauliche oder gesetzlich geschützte Daten > oder Informationen beinhalten. Falls Sie diese Nachricht irrtümlich > erreicht hat, bitten wir Sie höflich, diese unter Ausschluss jeglicher > Reproduktion zu löschen und die absendende Person zu benachrichtigen. Danke > für Ihre Hilfe. > > This message and any attached files are for the sole use of the recipient > named above. It may contain confidential or legally protected data or > information. If you have received this message in error, please delete it > without making any copies whatsoever and notify the sender. Thank you for > your assistance. >
