Geo-rep start after snapshot restore makes the geo-rep faulty

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Geo-rep start after snapshot restore makes the geo-rep faulty

Shwetha Acharya
Hi All,
I am planning to work on this 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

_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

Re: Geo-rep start after snapshot restore makes the geo-rep faulty

RAFI KC


On 9/23/19 4:13 PM, Shwetha Acharya wrote:
Hi All,
I am planning to work on this 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.

Rafi

Are there any other general concerns regarding the same?

Regards,
Shwetha

_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

Re: Geo-rep start after snapshot restore makes the geo-rep faulty

Shwetha Acharya
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.  [hidden email] [hidden email]  Any pointers on this?

Regards,
Shwetha

On Mon, Sep 23, 2019 at 5:53 PM RAFI KC <[hidden email]> wrote:


On 9/23/19 4:13 PM, Shwetha Acharya wrote:
Hi All,
I am planning to work on this 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.

Rafi

Are there any other general concerns regarding the same?

Regards,
Shwetha

_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

Re: Geo-rep start after snapshot restore makes the geo-rep faulty

RAFI KC

If that is the case, then we don't need to do anything from snapshot point of view.


Regards

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.  [hidden email] [hidden email]  Any pointers on this?

Regards,
Shwetha

On Mon, Sep 23, 2019 at 5:53 PM RAFI KC <[hidden email]> wrote:


On 9/23/19 4:13 PM, Shwetha Acharya wrote:
Hi All,
I am planning to work on this 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.

Rafi

Are there any other general concerns regarding the same?

Regards,
Shwetha

_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

Re: Geo-rep start after snapshot restore makes the geo-rep faulty

Shwetha Acharya
Thank you for the clarification. 

On Mon, Sep 23, 2019 at 6:12 PM RAFI KC <[hidden email]> wrote:

If that is the case, then we don't need to do anything from snapshot point of view.


Regards

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.  [hidden email] [hidden email]  Any pointers on this?

Regards,
Shwetha

On Mon, Sep 23, 2019 at 5:53 PM RAFI KC <[hidden email]> wrote:


On 9/23/19 4:13 PM, Shwetha Acharya wrote:
Hi All,
I am planning to work on this 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.

Rafi

Are there any other general concerns regarding the same?

Regards,
Shwetha

_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

Re: Geo-rep start after snapshot restore makes the geo-rep faulty

Aravinda Vishwanathapura Krishna Murthy
In reply to this post by Shwetha Acharya
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.


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 <[hidden email]> wrote:
Hi All,
I am planning to work on this 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

_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel

Reply | Threaded
Open this post in threaded view
|

Re: Geo-rep start after snapshot restore makes the geo-rep faulty

Shwetha Acharya
Hi Aravinda,

Thanks for the update. I will get back to you in case of any queries.

On Tue, Sep 24, 2019 at 8:20 AM Aravinda Vishwanathapura Krishna Murthy <[hidden email]> wrote:
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.


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 <[hidden email]> wrote:
Hi All,
I am planning to work on this 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

_______________________________________________

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-devel mailing list
[hidden email]
https://lists.gluster.org/mailman/listinfo/gluster-devel