Re: [Dev] For reference - data changes between MB 3.1.0 and MB 3.2.0 (internal feature)

[Sasikala Kottegoda]

Hi Hasitha,

Following are the changes in MB 3.2.0 compared to 3.1.0 in a summary as I
can see.

   1. Changes in subscriptions data in MB_DURABLE_SUBSCRIPTION
   2. Simplified queue data in MB_QUEUE
   3. Simplified  binding data in MB_BINDINGS
   4. All queue names being lower case

We have already written a tool to cater the first 3 requirements. What is
remaining is to only change the queue names to lower case which was
intorduced recently.

Regarding the concerns on the changes in subscription data, we actually
have to do almost nothing since there won't be any active subscriptions
when the system is migrated. We only need to remove all susbription entries
from the table so that new subscriptions to MB 3.2.0 will be of the new
format.

Ragarding your suggestion on the approach for migration, we cannot wait
until all the subscriptions are done consuming since there could be
inactive subscribers, slow subscribers, a large number of pending messages,
etc. In that case, what we can do is to provide a migration client which
will consume from MB 3.1.0 and publish to MB 3.2.0 as in what we have
suggested in [1].

If the system could have a down time, both approaches would be okay. Where
as, if we need to migrate with zero down time, we'll need to go with the
first approach which is to write a mgration tool.

[1] https://docs.wso2.com/display/MB300/Upgrading+from+a+Previous+Release

Thank you,
Sasikala

On Sun, Apr 2, 2017 at 8:41 PM, Ramith Jayasinghe  wrote:

> whats the possibility of writing a tool which can migrate the data?
>
>
> On Sun, Apr 2, 2017 at 7:53 PM, Hasitha Hiranya  wrote:
>
>> Hi,
>>
>> Please see attached.
>>
>> 1. Queue names should be fixed in about 5 tables (make all simple)
>> 2. Queue data string is updated in the model
>> 3. Subscriber data string is updated in the model
>> 4. Subscriber has a UUID as subscriber ID now.
>> 5. Subscriber connection is base64 encoded. Code will decode and work. In
>> 3.1.0 there was nothing like that.
>> 6. Inactive durable topic subscribers are derived from the queues now. No
>> entries in subscriber table.
>>
>>
>> Since there is a lot of changes in schema and code, IMO migrating from
>> 3.1.0 to 3.2.0 is error prone. Mainly this is because the model of working
>> is different now.
>>
>> Can we migrate a production MB customer to EI using below approach?
>>
>> 1. Create an EI cluster. MB cluster is in production.
>> 2. Switch publishers to EI cluster. Let subscribers be done with MB
>> cluster
>> 3. Switch subscribers also to EI cluster.
>>
>> For durable topic/queue subscribers above should work.
>>
>> WDYT?
>>
>>
>> --
>> *Hasitha Abeykoon*
>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>> *cell:* *+94 719363063*
>> *blog: **abeykoon.blogspot.com* 
>>
>>
>
>
> --
> Ramith Jayasinghe
> Technical Lead
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> E: ram...@wso2.com
> P: +94 777542851 <+94%2077%20754%202851>
>



-- 
Sasikala Kottegoda
*Software Engineer*
WSO2 Inc., http://wso2.com/
lean. enterprise. middleware
Mobile: +94 774835928

[image: https://wso2.com/signature] 
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] For reference - data changes between MB 3.1.0 and MB 3.2.0 (internal feature)

[Ramith Jayasinghe]

whats the possibility of writing a tool which can migrate the data?


On Sun, Apr 2, 2017 at 7:53 PM, Hasitha Hiranya  wrote:

> Hi,
>
> Please see attached.
>
> 1. Queue names should be fixed in about 5 tables (make all simple)
> 2. Queue data string is updated in the model
> 3. Subscriber data string is updated in the model
> 4. Subscriber has a UUID as subscriber ID now.
> 5. Subscriber connection is base64 encoded. Code will decode and work. In
> 3.1.0 there was nothing like that.
> 6. Inactive durable topic subscribers are derived from the queues now. No
> entries in subscriber table.
>
>
> Since there is a lot of changes in schema and code, IMO migrating from
> 3.1.0 to 3.2.0 is error prone. Mainly this is because the model of working
> is different now.
>
> Can we migrate a production MB customer to EI using below approach?
>
> 1. Create an EI cluster. MB cluster is in production.
> 2. Switch publishers to EI cluster. Let subscribers be done with MB cluster
> 3. Switch subscribers also to EI cluster.
>
> For durable topic/queue subscribers above should work.
>
> WDYT?
>
>
> --
> *Hasitha Abeykoon*
> Senior Software Engineer; WSO2, Inc.; http://wso2.com
> *cell:* *+94 719363063*
> *blog: **abeykoon.blogspot.com* 
>
>


-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: ram...@wso2.com
P: +94 777542851
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] For reference - data changes between MB 3.1.0 and MB 3.2.0 (internal feature)

[Hasitha Hiranya]

Hi,

Please see attached.

1. Queue names should be fixed in about 5 tables (make all simple)
2. Queue data string is updated in the model
3. Subscriber data string is updated in the model
4. Subscriber has a UUID as subscriber ID now.
5. Subscriber connection is base64 encoded. Code will decode and work. In
3.1.0 there was nothing like that.
6. Inactive durable topic subscribers are derived from the queues now. No
entries in subscriber table.


Since there is a lot of changes in schema and code, IMO migrating from
3.1.0 to 3.2.0 is error prone. Mainly this is because the model of working
is different now.

Can we migrate a production MB customer to EI using below approach?

1. Create an EI cluster. MB cluster is in production.
2. Switch publishers to EI cluster. Let subscribers be done with MB cluster
3. Switch subscribers also to EI cluster.

For durable topic/queue subscribers above should work.

WDYT?


-- 
*Hasitha Abeykoon*
Senior Software Engineer; WSO2, Inc.; http://wso2.com
*cell:* *+94 719363063*
*blog: **abeykoon.blogspot.com* 


data changes between mb 3.1.0 and 3.2.0
Description: Binary data
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev