[infinispan-dev] Cache migration (rolling upgrades, dump/restore, etc)

[Gustavo Fernandes]

On Mon, May 22, 2017 at 1:59 PM, Martin Gencur <mgencur at redhat.com> wrote:

> Hi Wolf,
> that was exactly my thought. Clients redirected to the target cluster do
> not get updates written by other clients in the source cluster during the
> rolling upgrade process. It is because the clients in target cluster won't
> read the data through the remote cache store if they already have the
> requested key in the local memory.
>


No, it won't, the source cluster is not supposed to be written to during
Rolling Upgrade. That's why the "L4" will prevent that. As per Wolf's
comments:

> a client might still have a request to the source until other clients are
moved to target and already accessed the key

The source cluster will enter a "redirect" mode. Every new client and new
operation will be sent to the new cluster.
Ongoing operations will need to be re-done in the new cluster.

> a new client connects with old properties, here we need to ensure that
the first request is redirected to the target and not update the source

The old server will be in "redirect" mode, this new client will be
redirected to the new cluster. After the RU completes, this new client will
not
be able to connect anymore since the old cluster will have been destroyed.

Is there a BZ/JIRA for this?
>

It will follow soon. In the meantime, please make sure clients are pointing
to the new server.

Gustavo


> Martin
>
>
> On 19.5.2017 13:17, Wolf Fink wrote:
>
> +1 for Vojtech
>
> yes the client's need to moved to the new cluster in one shot current,
> that was discussed  before.
> And it makes the migration because most of the customers are not able to
> make that happen.
> So there is a small possibility of inconsistence if clients connect to the
> old server update entries until the new server already migrated it.
>
> I see two options
> 1)
> source server need to propagate active to target on update
> 2)
> with the new L4 strategy all clients are moved automatically to the
> target. So the source is not updated.
> I only see a small possibility for this to happen during switch
> - a client might still have a request to the source until other clients
> are moved to target and already accessed the key
> - a new client connects with old properties, here we need to ensure that
> the first request is redirected to the target and not update the source
>
> On Fri, May 19, 2017 at 12:50 PM, Vojtech Juranek <vjuranek at redhat.com>
> wrote:
>
>> On středa 17. května 2017 16:56:25 CEST Tristan Tarrant wrote:
>> > 2) Need a way to "rollback" the process in case of failures during the
>> > migration: redirecting the clients back to the original cluster without
>> > data loss. This would use the above L4 strategy.
>>
>> it's not only about redirecting clients - IIRC newly created entries on
>> target
>> cluster are not propagated back to source cluster during rolling upgrade,
>> so
>> we need also somehow sync these new data back to source cluster during the
>> rollback to avoid data losses. Same applies to "cancel process" feature
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
> _______________________________________________
> infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170522/efffd05c/attachment.html