<div dir="ltr">Can we re-visit this thread?<div><br></div><div>Aravinda, Would be great to add it to github issues, so we can pursue this forward there.</div><div><br></div><div>-Amar</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 5, 2016 at 2:48 PM, Aravinda <span dir="ltr">&lt;<a href="mailto:avishwan@redhat.com" target="_blank">avishwan@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Gluster Snapshots and Geo-replication are not well integrated, lot of<br>
steps to be performed to take snapshot of Gluster Volume which is<br>
Geo-replicated. Proposed enhancement for Geo-replication to understand<br>
Snapshot better and automatically handle Slave side snapshot.<br>
<br>
Proposed Solution:<br>
------------------<br>
Take Gluster Snapshot and set Geo-replication Config<br>
`current-snapshot` using,<br>
<br>
    gluster volume geo-replication &lt;MASTERVOL&gt; &lt;SLAVEHOST&gt;::&lt;SLAVEVOL&gt; \<br>
        config current_snapshot &lt;SNAPNAME&gt;<br>
<br>
Geo-rep will automatically restart on config change and new config<br>
will act as switch to use Snapshot or Live Volume.<br>
<br>
Geo-rep will mount snapshot Volume in Master instead of Live<br>
Volume, so that Geo-rep can sync the changes from Snapshot Volume<br>
instead of live volume. Along with the mount Geo-rep should use the<br>
back end changelogs of snapshot brick instead of live brick.<br>
<br>
Geo-rep worker will update stime both in snapshot bricks and live<br>
bricks, this is required to prevents re-processing changelogs which<br>
are already processed when switched to live Changelogs.<br>
<br>
Once all the changes from Snapshot synced to slave then Geo-rep worker<br>
will trigger snapshot at slave side. On successful slave snapshot<br>
Geo-replication will automatically switches to live Volume by<br>
resetting current_snapshot option.<br>
<br>
Snapshot Restore:<br>
-----------------<br>
Restore both Slave and Master Volume to the same Snapshot name,<br>
Geo-rep should work without any further changes.<br>
<br>
Challenges:<br>
-----------<br>
- Geo-rep may not work as expected if we give old snapshot name after<br>
  latest snapshot name.<br>
- Detecting the completion of sync from Snapshot Volume(Checkpoint?)<br>
- Since Changelogs are generated even in Snapshot Volume, updating stime<br>
  on live bricks while syncing from snapshot Volume brick may cause problems<br>
  when switched back to live.<br>
- Finding respective snapshot brick path from live volume brick path may be<br>
  challenging if Bricks removed/added after taking snapshot.<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
regards<br>
Aravinda<br>
<br>
______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman<wbr>/listinfo/gluster-devel</a><br>
</font></span></blockquote></div><br></div>