<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 22, 2017 at 1:59 PM, Martin Gencur <span dir="ltr"><<a href="mailto:mgencur@redhat.com" target="_blank">mgencur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
Hi Wolf,<br>
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. </div></blockquote><div><br><br></div><div>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:<br><br></div><div>> a client might still have a request to the source until
other clients are moved to target and already accessed the key<br><br></div><div>The source cluster will enter a "redirect" mode. Every new client and new operation will be sent to the new cluster.<br></div><div>Ongoing operations will need to be re-done in the new cluster.<br><br>> 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<br><br></div><div>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 <br></div><div>be able to connect anymore since the old cluster will have been destroyed.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">Is there a BZ/JIRA for this?<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></div></blockquote><div><br></div><div>It will follow soon. In the meantime, please make sure clients are pointing to the new server.<br><br></div><div>Gustavo<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-HOEnZb"><font color="#888888">
<br>
Martin</font></span><div><div class="gmail-h5"><br>
<br>
<div class="gmail-m_7300703937199371989moz-cite-prefix">On 19.5.2017 13:17, Wolf Fink wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>+1 for Vojtech<br>
<br>
</div>
yes the client's need to moved to the new
cluster in one shot current, that was discussed
before.<br>
</div>
And it makes the migration because most of the
customers are not able to make that happen.<br>
</div>
So there is a small possibility of inconsistence if
clients connect to the old server update entries
until the new server already migrated it.<br>
<br>
</div>
I see two options<br>
1)<br>
</div>
source server need to propagate active to target on
update<br>
2)<br>
</div>
with the new L4 strategy all clients are moved
automatically to the target. So the source is not updated.<br>
</div>
I only see a small possibility for this to happen during
switch<br>
</div>
- a client might still have a request to the source until
other clients are moved to target and already accessed the key<br>
</div>
- 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<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 19, 2017 at 12:50 PM,
Vojtech Juranek <span dir="ltr"><<a href="mailto:vjuranek@redhat.com" target="_blank">vjuranek@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On středa 17. května 2017 16:56:25 CEST Tristan
Tarrant wrote:<br>
> 2) Need a way to "rollback" the process in case of
failures during the<br>
> migration: redirecting the clients back to the
original cluster without<br>
> data loss. This would use the above L4 strategy.<br>
<br>
</span>it's not only about redirecting clients - IIRC newly
created entries on target<br>
cluster are not propagated back to source cluster during
rolling upgrade, so<br>
we need also somehow sync these new data back to source
cluster during the<br>
rollback to avoid data losses. Same applies to "cancel
process" feature<br>
______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/infinispan-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="gmail-m_7300703937199371989mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
infinispan-dev mailing list
<a class="gmail-m_7300703937199371989moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a>
<a class="gmail-m_7300703937199371989moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a></pre>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br></blockquote></div><br></div></div>