You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Nordstrom, Karl" <kx...@psu.edu> on 2021/11/18 16:12:39 UTC

ActiveMQ upgrade documentation

Is there documentation on how to upgrade ActiveMQ classic?
I want to upgrade our test cluster from 1.15.12 to 1.16.3 and
our production cluster from 1.16.0 to 1.16.3.
We are using KahaDB version 6.

Thanks

---

Karl Nordström

Systems Administrator

Penn State IT | Application Platforms

Re: ActiveMQ upgrade documentation

Posted by Matt Pavlovich <ma...@gmail.com>.
Hi Karl-

You are welcome! Let us know how it goes, I would not expect any issues for an upgrade between those versions.

-Matt Pavlovich

> On Nov 18, 2021, at 1:07 PM, Nordstrom, Karl <kx...@psu.edu> wrote:
> 
> Hello Matt,
> 
> Thanks for the reply. Yes, I meant 5.15.12 and 5.16.3. I doubt I'll be able to get the software engineers to drain the production queues. I have an active and passive server in each cluster. I'm hoping to upgrade the passive server first, then making it the active server. Then upgrade the original active host. Can the KahaDB tolerate both 5.15 and 5.16 servers accessing the same database at the same time?
> 
> 
> ---
> 
> Karl Nordström
> 
> Systems Administrator
> 
> Penn State IT | Application Platforms
> 
> ________________________________
> From: Matt Pavlovich <ma...@gmail.com>
> Sent: Thursday, November 18, 2021 1:27 PM
> To: users@activemq.apache.org <us...@activemq.apache.org>
> Subject: Re: ActiveMQ upgrade documentation
> 
> Hello Karl-
> 
> The upgrade should be pretty straight forward for those versions. You had typed ‘1.15.12’ and ‘1.16.3’— I suspect you meant ‘5.15.12’ and ’5.16.3’.
> 
> If you can have all the applications ‘drain’ all messages, that is the best. You then get fresh kahadb files created by 5.16.3.
> 
> Otherwise:
> 1. Take note of queues and # of messages in each
> 2. Stop the old 5.15.12
> 2. Copy the kahadb files from 5.15.12 to the new 5.16.3
> 3. Start up the new 5.16.3
> 4. Verify queues and message counts
> 
> Hope this helps!
> 
> Thanks,
> Matt
> 
>> On Nov 18, 2021, at 10:12 AM, Nordstrom, Karl <kx...@psu.edu> wrote:
>> 
>> Is there documentation on how to upgrade ActiveMQ classic?
>> I want to upgrade our test cluster from 1.15.12 to 1.16.3 and
>> our production cluster from 1.16.0 to 1.16.3.
>> We are using KahaDB version 6.
>> 
>> Thanks
>> 
>> ---
>> 
>> Karl Nordström
>> 
>> Systems Administrator
>> 
>> Penn State IT | Application Platforms
> 


Re: ActiveMQ upgrade documentation

Posted by "Nordstrom, Karl" <kx...@psu.edu>.
Tim,

Thanks for pointing out that only one broker accesses the data at a time.

I will do the upgrade in dev, then acceptance, before doing it in the production environment.


---

Karl Nordström

Systems Administrator

Penn State IT | Application Platforms

________________________________
From: Tim Bain <tb...@alumni.duke.edu>
Sent: Friday, November 19, 2021 7:44 AM
To: ActiveMQ Users <us...@activemq.apache.org>
Subject: Re: ActiveMQ upgrade documentation

Only one ActiveMQ broker accesses the data store at a time. The passive
node is simply waiting to acquire the lock but will not access the data
store until the lock is acquired.

Yes, it's possible to do a rolling upgrade as you described,. The downtime
incurred will be minimal (just a standard failover), but if your producers
and consumers are still active then you won't be able to do the sanity
checks Matt recommended.

If doing those is important to you, you'll need to stop all clients from
interacting with the brokers (either by stopping all clients or by doing
something at the network level to prevent clients from reaching the broker)
before bringing down the second broker. If it was me, I would test the
upgrade in a dev environment (making sure there are unconsumed messages in
the data store that I saw consumed after the upgrade) and then not do the
verification in test/prod. My philosophy is that any concerns about whether
a deployment will work should be addressed before you do it in production,
but you'll have to assess what's right for your organization and its
culture.

Tim

On Thu, Nov 18, 2021, 12:07 PM Nordstrom, Karl <kx...@psu.edu> wrote:

> Hello Matt,
>
> Thanks for the reply. Yes, I meant 5.15.12 and 5.16.3. I doubt I'll be
> able to get the software engineers to drain the production queues. I have
> an active and passive server in each cluster. I'm hoping to upgrade the
> passive server first, then making it the active server. Then upgrade the
> original active host. Can the KahaDB tolerate both 5.15 and 5.16 servers
> accessing the same database at the same time?
>
>
> ---
>
> Karl Nordström
>
> Systems Administrator
>
> Penn State IT | Application Platforms
>
> ________________________________
> From: Matt Pavlovich <ma...@gmail.com>
> Sent: Thursday, November 18, 2021 1:27 PM
> To: users@activemq.apache.org <us...@activemq.apache.org>
> Subject: Re: ActiveMQ upgrade documentation
>
> Hello Karl-
>
> The upgrade should be pretty straight forward for those versions. You had
> typed ‘1.15.12’ and ‘1.16.3’— I suspect you meant ‘5.15.12’ and ’5.16.3’.
>
> If you can have all the applications ‘drain’ all messages, that is the
> best. You then get fresh kahadb files created by 5.16.3.
>
> Otherwise:
> 1. Take note of queues and # of messages in each
> 2. Stop the old 5.15.12
> 2. Copy the kahadb files from 5.15.12 to the new 5.16.3
> 3. Start up the new 5.16.3
> 4. Verify queues and message counts
>
> Hope this helps!
>
> Thanks,
> Matt
>
> > On Nov 18, 2021, at 10:12 AM, Nordstrom, Karl <kx...@psu.edu> wrote:
> >
> > Is there documentation on how to upgrade ActiveMQ classic?
> > I want to upgrade our test cluster from 1.15.12 to 1.16.3 and
> > our production cluster from 1.16.0 to 1.16.3.
> > We are using KahaDB version 6.
> >
> > Thanks
> >
> > ---
> >
> > Karl Nordström
> >
> > Systems Administrator
> >
> > Penn State IT | Application Platforms
>
>

Re: ActiveMQ upgrade documentation

Posted by Tim Bain <tb...@alumni.duke.edu>.
Only one ActiveMQ broker accesses the data store at a time. The passive
node is simply waiting to acquire the lock but will not access the data
store until the lock is acquired.

Yes, it's possible to do a rolling upgrade as you described,. The downtime
incurred will be minimal (just a standard failover), but if your producers
and consumers are still active then you won't be able to do the sanity
checks Matt recommended.

If doing those is important to you, you'll need to stop all clients from
interacting with the brokers (either by stopping all clients or by doing
something at the network level to prevent clients from reaching the broker)
before bringing down the second broker. If it was me, I would test the
upgrade in a dev environment (making sure there are unconsumed messages in
the data store that I saw consumed after the upgrade) and then not do the
verification in test/prod. My philosophy is that any concerns about whether
a deployment will work should be addressed before you do it in production,
but you'll have to assess what's right for your organization and its
culture.

Tim

On Thu, Nov 18, 2021, 12:07 PM Nordstrom, Karl <kx...@psu.edu> wrote:

> Hello Matt,
>
> Thanks for the reply. Yes, I meant 5.15.12 and 5.16.3. I doubt I'll be
> able to get the software engineers to drain the production queues. I have
> an active and passive server in each cluster. I'm hoping to upgrade the
> passive server first, then making it the active server. Then upgrade the
> original active host. Can the KahaDB tolerate both 5.15 and 5.16 servers
> accessing the same database at the same time?
>
>
> ---
>
> Karl Nordström
>
> Systems Administrator
>
> Penn State IT | Application Platforms
>
> ________________________________
> From: Matt Pavlovich <ma...@gmail.com>
> Sent: Thursday, November 18, 2021 1:27 PM
> To: users@activemq.apache.org <us...@activemq.apache.org>
> Subject: Re: ActiveMQ upgrade documentation
>
> Hello Karl-
>
> The upgrade should be pretty straight forward for those versions. You had
> typed ‘1.15.12’ and ‘1.16.3’— I suspect you meant ‘5.15.12’ and ’5.16.3’.
>
> If you can have all the applications ‘drain’ all messages, that is the
> best. You then get fresh kahadb files created by 5.16.3.
>
> Otherwise:
> 1. Take note of queues and # of messages in each
> 2. Stop the old 5.15.12
> 2. Copy the kahadb files from 5.15.12 to the new 5.16.3
> 3. Start up the new 5.16.3
> 4. Verify queues and message counts
>
> Hope this helps!
>
> Thanks,
> Matt
>
> > On Nov 18, 2021, at 10:12 AM, Nordstrom, Karl <kx...@psu.edu> wrote:
> >
> > Is there documentation on how to upgrade ActiveMQ classic?
> > I want to upgrade our test cluster from 1.15.12 to 1.16.3 and
> > our production cluster from 1.16.0 to 1.16.3.
> > We are using KahaDB version 6.
> >
> > Thanks
> >
> > ---
> >
> > Karl Nordström
> >
> > Systems Administrator
> >
> > Penn State IT | Application Platforms
>
>

Re: ActiveMQ upgrade documentation

Posted by "Nordstrom, Karl" <kx...@psu.edu>.
Hello Matt,

Thanks for the reply. Yes, I meant 5.15.12 and 5.16.3. I doubt I'll be able to get the software engineers to drain the production queues. I have an active and passive server in each cluster. I'm hoping to upgrade the passive server first, then making it the active server. Then upgrade the original active host. Can the KahaDB tolerate both 5.15 and 5.16 servers accessing the same database at the same time?


---

Karl Nordström

Systems Administrator

Penn State IT | Application Platforms

________________________________
From: Matt Pavlovich <ma...@gmail.com>
Sent: Thursday, November 18, 2021 1:27 PM
To: users@activemq.apache.org <us...@activemq.apache.org>
Subject: Re: ActiveMQ upgrade documentation

Hello Karl-

The upgrade should be pretty straight forward for those versions. You had typed ‘1.15.12’ and ‘1.16.3’— I suspect you meant ‘5.15.12’ and ’5.16.3’.

If you can have all the applications ‘drain’ all messages, that is the best. You then get fresh kahadb files created by 5.16.3.

Otherwise:
1. Take note of queues and # of messages in each
2. Stop the old 5.15.12
2. Copy the kahadb files from 5.15.12 to the new 5.16.3
3. Start up the new 5.16.3
4. Verify queues and message counts

Hope this helps!

Thanks,
Matt

> On Nov 18, 2021, at 10:12 AM, Nordstrom, Karl <kx...@psu.edu> wrote:
>
> Is there documentation on how to upgrade ActiveMQ classic?
> I want to upgrade our test cluster from 1.15.12 to 1.16.3 and
> our production cluster from 1.16.0 to 1.16.3.
> We are using KahaDB version 6.
>
> Thanks
>
> ---
>
> Karl Nordström
>
> Systems Administrator
>
> Penn State IT | Application Platforms


Re: ActiveMQ upgrade documentation

Posted by Matt Pavlovich <ma...@gmail.com>.
Hello Karl-

The upgrade should be pretty straight forward for those versions. You had typed ‘1.15.12’ and ‘1.16.3’— I suspect you meant ‘5.15.12’ and ’5.16.3’.

If you can have all the applications ‘drain’ all messages, that is the best. You then get fresh kahadb files created by 5.16.3. 

Otherwise:
1. Take note of queues and # of messages in each
2. Stop the old 5.15.12
2. Copy the kahadb files from 5.15.12 to the new 5.16.3
3. Start up the new 5.16.3
4. Verify queues and message counts

Hope this helps!

Thanks,
Matt

> On Nov 18, 2021, at 10:12 AM, Nordstrom, Karl <kx...@psu.edu> wrote:
> 
> Is there documentation on how to upgrade ActiveMQ classic?
> I want to upgrade our test cluster from 1.15.12 to 1.16.3 and
> our production cluster from 1.16.0 to 1.16.3.
> We are using KahaDB version 6.
> 
> Thanks
> 
> ---
> 
> Karl Nordström
> 
> Systems Administrator
> 
> Penn State IT | Application Platforms


Re: ActiveMQ upgrade documentation

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Karl,

It's possible to setup a master/slave or NoB between the "old" version 
and the "new" one, in order to do a "live" update.

Regards
JB

On 18/11/2021 17:12, Nordstrom, Karl wrote:
> Is there documentation on how to upgrade ActiveMQ classic?
> I want to upgrade our test cluster from 1.15.12 to 1.16.3 and
> our production cluster from 1.16.0 to 1.16.3.
> We are using KahaDB version 6.
> 
> Thanks
> 
> ---
> 
> Karl Nordström
> 
> Systems Administrator
> 
> Penn State IT | Application Platforms
>