One approach that may work for you: stand up new brokers with the upgrade,
temporarily network the old broker to the new, force all clients to
reconnect to the new.
In order for that to work, the clients need to know to connect to the new
brokers before they are stood up. The failover transport c
The brokers are standalone, not master/slave so it looks like there may
need to be a short outage while we upgrade. Does anyone else have this
configuration that has upgraded? Is there anyway around taking an outage?
On 10/20/14, 6:19 PM, "artnaseef" wrote:
>Yeah, it should work fine. Just keep
Yeah, it should work fine. Just keep in mind that messages on a broker are
only reactively moved to another broker, and they only ever live on a single
broker at a time (for the most part).
So, shutting down a broker with messages that have not drained will either
lose those messages (for non-per
We have a hub/spoke architecture. We did a rolling upgrade from 5.7.0 to
5.10.0 starting with the hub instance. So long as the client/server & peer
protocols don't become incompatible it's fine.
On 15 October 2014 21:39, djdick wrote:
> We're looking to upgrade from 5.9 to 5.10 and are using a n
We're looking to upgrade from 5.9 to 5.10 and are using a network of brokers
topology. In order to keep downtime to a minimum we're looking at upgrading
one server at a time while keeping the other servers active. For example
server A stays active while we shutdown server B and upgrade from 5.9 to
