[Gluster-devel] Geo-rep start after snapshot restore makes the geo-rep faulty
sacharya at redhat.com
Mon Sep 23 12:45:37 UTC 2019
Thank you for the clarification.
On Mon, Sep 23, 2019 at 6:12 PM RAFI KC <rkavunga at redhat.com> wrote:
> If that is the case, then we don't need to do anything from snapshot point
> of view.
> Rafi KC
> On 9/23/19 6:09 PM, Shwetha Acharya wrote:
> We are thinking of eliminating path from index file, instead of replacing
> it. We need to further see if it is feasible to do so. I am looking into
> it. @Aravinda Vishwanathapura Krishna Murthy <avishwan at redhat.com> @Kotresh
> Hiremath Ravishankar <khiremat at redhat.com> Any pointers on this?
> On Mon, Sep 23, 2019 at 5:53 PM RAFI KC <rkavunga at redhat.com> wrote:
>> On 9/23/19 4:13 PM, Shwetha Acharya 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?
>> Can you please explain how we are planning to replace the path in the
>> index file. Did we finalized the method? The problem here is that any time
>> consuming operation within the glusterd transaction could be a difficult.
>> Are there any other general concerns regarding the same?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel