<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 1:08 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</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">Just throwing out an idea I just had while thinking of Hibernate OGM<br>
user needs for data migration.<br>
<br>
For people using databases & related frameworks, it's common to have a<br>
staging database which contains not just the staging "schema" but also<br>
data. When legally possible, it's often preferable to have snapshot<br>
from production data.<br>
<br>
For example last time I worked with a SQL database, each week I'd take<br>
a production backup and restore it on both our staging environment and<br>
on the developer's instances so that everyone could run tests on it -<br>
without needing access to the real production.<br>
<br>
Interestingly, while we don't have an easy tool get a fully consistent<br>
snapshot from a live Infinispan grid, "replicating" should be a<br>
familiar concept here?<br></blockquote><div><br></div><div>We do have a way to "copy" data from a grid, which is part of the Rolling Upgrade process [1], which is <br></div><div>supposed to migrate data from one cluster to another with no downtime for clients. Both clusters<br></div><div>are independent and can have incompatible Infinispan version, like 8.x and 9.x.<br><br>Re-using some parts of the Rolling Upgrade from [1], it'd be possible to extract a tool that simply grabs data from a <br>running cluster and save it to another without the clients accessing the source cluster being aware of it. Although<br></div><div>not technically a snapshot, it fits the use case of pre-production environment provisioning.<br></div><div><br>[1] <a href="http://infinispan.org/docs/dev/user_guide/user_guide.html#rolling_upgrades_for_infinispan_servers">http://infinispan.org/docs/dev/user_guide/user_guide.html#rolling_upgrades_for_infinispan_servers</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Infinispan could have a "mitosis" feature, like cell reproduction, in<br>
which the user connects a pristine grid instance of N nodes and these<br>
N nodes automatically become non-primary owners for the full set of<br>
segments - this could happen via a custom hash which makes them all<br>
backup replicas (no main owners) and then Infinispan would be able to<br>
tell when state transfer is completed, and initiate some some<br>
coordination to sever the link without triggering re-hash on the<br>
original "production" grid.<br>
<br>
Incidentally, while this happens the child datagrid would be kept up<br>
to date with in-flight changes, so we could envision either a very<br>
short lock on changes to guarantee a fully consistent snapshot, or not<br>
have any lock at all but minimise the inconsistencies to those which<br>
might happen during the link decoupling.<br>
<br>
Maybe this would satisfy also the people who've been asking for the<br>
snapshot feature? I don't think people want a snapshot for the sake of<br>
it, but to replicate the grid..<br>
<br>
I realise it's not a 1 day of work and the idea is not fully fleshed<br>
out, but I think this would be a very well received feature.<br>
<br>
<br>
Thanks,<br>
Sanne<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>