[Gluster-users] geo replication help

[Niels de Vos]

On Wed, Sep 03, 2014 at 09:00:09PM +0530, M S Vishwanath Bhat wrote:
> On 03/09/14 20:31, David F. Robinson wrote:
> >Is this bug-fix going to be in the 3.5.3 beta release?
> Not sure. I will have to check that. AFAIK the patches are present in
> upstream and 3.6 branch. Is upgrading to 3.6 an option?

Could you point out which patch(es) these are? If they are simple
enough, we can definitely include them in a 3.5.x release.

Thanks,
Niels

> 
> Best Regards,
> Vishwanath
> 
> >
> >David
> >
> >
> >------ Original Message ------
> >From: "Niels de Vos" <ndevos at redhat.com>
> >To: "M S Vishwanath Bhat" <vbhat at redhat.com>
> >Cc: "David F. Robinson" <david.robinson at corvidtec.com>;
> >gluster-users at gluster.org
> >Sent: 8/15/2014 6:25:04 AM
> >Subject: Re: [Gluster-users] geo replication help
> >
> >>On Wed, Aug 13, 2014 at 04:17:11PM +0530, M S Vishwanath Bhat wrote:
> >>> On 13/08/14 02:27, David F. Robinson wrote:
> >>> >I was hoping someone could help me debug my geo-replication under
> >>> >gluster 3.5.2.
> >>> >I am trying to use geo-replication to create a lagged backup of my
> >>> >data. What I wanted to do was to turn off the geo-replication
> >>> >(gluster volume geo-replication homegfs
> >>> >gfsib01bkp.corvidtec.com::homegfs_bkp stop) during the day, and
> >>> >then turn it back on at midnight to allow the remote system to
> >>> >sync.
> >>> >If I stop the geo-replication, delete a file, and then restart the
> >>> >geo-replication, the deletion never shows up on the slave system.
> >>> >From the website below, I thought that it would pick up these
> >>> >changes. Any suggestions for how I can get the changes made while
> >>> >the geo-replication is stopped to propagate after restart the
> >>> >geo-replication?
> >>> This is a known issue with glusterfs-3.5.2. The problem is xsync can
> >>> not handle deletes and renames. So when you restart the geo-rep, the
> >>> change detection mechanism falls back to xsync even though the
> >>> Changelog was ON, the whole time. So deletes and renames won't be
> >>> propagated to slave in 3.5.2
> >>>
> >>> The patch to fix this issue is already submitted and is present in
> >>> glusterfs master branch. The fix should be available in
> >>> glusterfs-3.6 soon.
> >>
> >>Can you point me to the bug/patch, or clone the bug for 3.5 and provide
> >>a backport?
> >>
> >>Thanks,
> >>Niels
> >>
> >>>
> >>> Best Regards,
> >>> Vishwanath
> >>>
> >>>
> >>>>https://medium.com/@msvbhat/distributed-geo-replication-in-glusterfs-ec95f4393c50
> >>>
> >>> >
> >>> >*/gluster volume geo-replication <master_volume>
> >>> ><slave_volume>::<slave_volume> stop [force]/*
> >>> >
> >>> >Force option is to be used, when one of the node (or glusterd in
> >>> >one of the node) is down. Once stopped, the session can be
> >>> >restarted any time. Note that upon restarting of the session, the
> >>> >change detection mechanism falls back to xsync mode. This happens
> >>> >even though you have changelog generating journals, while the
> >>> >geo-rep session is stopped.
> >>> >
> >>> >
> >>> >
> >>> >_______________________________________________
> >>> >Gluster-users mailing list
> >>> >Gluster-users at gluster.org
> >>> >http://supercolony.gluster.org/mailman/listinfo/gluster-users
> >>>
> >>
> >>> _______________________________________________
> >>> Gluster-users mailing list
> >>> Gluster-users at gluster.org
> >>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
> >
>