activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Data Migration from KahaDB to LevelDB?
Date Mon, 09 Mar 2015 19:03:41 GMT
This solution works in certain situations, but there's currently no way to
cleanly migrate consumers to the new broker in all situations.  Scheduled
messages and non-durable topic subscriptions are two examples of cases
where simply standing up a new broker and having all clients move to it
isn't really a viable option at present.  There are a couple of threads
about the possibility of adding features to smoothly roll clients off of
one broker and onto another one (most recently a thread between me and
Kevin Burton and Art a month or so ago) if anyone wants background on the
subject...

On Mon, Mar 9, 2015 at 10:27 AM, Timothy Bish <tabish121@gmail.com> wrote:

> On 03/09/2015 11:54 AM, James A. Robinson wrote:
>
>> On Fri, Mar 6, 2015 at 6:07 AM, underflow <underflow@async.eu> wrote:
>>
>>> - Another idea was to create a network of brokers with the original
>>> instance
>>> (w/ kahadb persistence) and the new instance (w/ leveldb persistence) +
>>> resending all content, if required...
>>>
>> I'll be curious to see what advice you get.  I'm new to activemq, but this
>> sounds like a very reasonable approach to me.  I'd set up a cluster with
>> the new backing store and migrate clients to it.  Once I was happy the old
>> one is not needed I'd turn off the transport connectors and let it forward
>> any remaining data to the new cluster.
>>
>> Jim
>>
>>  This is in fact a reasonable solution.  This is also recommended when
> upgrading brokers even when using KahaDB so that messages from an older
> KahaDB version can be drained to the new broker.
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.bish@redhat.com | www.redhat.com
> skype: tabish121 | twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message