[Gluster-devel] Geo-rep start after snapshot restore makes the geo-rep faulty

[Aravinda Vishwanathapura Krishna Murthy]

Hi Shwetha,

Good to see this bug is picked up.

You are right, and the fix should be to remove the path from HTIME file.
RFE is already available here https://github.com/gluster/glusterfs/issues/76

There is one more RFE about optimizing Changelogs storage. Currently, all
changelogs are stored in a single directory, so this needs to be changed.
This affects the above RFE, instead of storing a complete changelog path in
HTIME file store with the prefix used in this RFE.

https://github.com/gluster/glusterfs/issues/154

These two RFE's to be worked together.

One major issue with format change is to handle the upgrades. Workaround
script to be used to upgrade existing HTIME file and new directory
structure of Changelog files.

Let me know if you have any questions.


On Mon, Sep 23, 2019 at 4:14 PM Shwetha Acharya <sacharya at redhat.com> wrote:

> Hi All,
> I am planning to work on this
> <https://bugzilla.redhat.com/show_bug.cgi?id=1238699> bugzilla issue.
> Here, when we restore the snapshots, and start the geo-replication
> session, we see that the geo-replication goes faulty. It is mainly because,
> the brick path of original session and the session after snapshot restore
> will be different. There is a proposed work around for this issue,
> according to which we replace the old brick path with new brick path inside
> the index file HTIME.xxxxxxxxxx, which basically solves the issue.
>
> I have some doubts regarding the same.
> We are going with the work around from a long time. Are there any
> limitations stopping us from implementing solution for this, which I am
> currently unaware of?
> Is it important to have paths inside index file? Can we eliminate the
> paths inside them?
> Is there any concerns from snapshot side?
> Are there any other general concerns regarding the same?
>
> Regards,
> Shwetha
>


-- 
regards
Aravinda VK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20190924/11e728ce/attachment.html>