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@xxxxxxxxxx> > >To: "M S Vishwanath Bhat" <vbhat@xxxxxxxxxx> > >Cc: "David F. Robinson" <david.robinson@xxxxxxxxxxxxx>; > >gluster-users@xxxxxxxxxxx > >Sent: 8/15/2014 6:25:04 AM > >Subject: Re: 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@xxxxxxxxxxx > >>> >http://supercolony.gluster.org/mailman/listinfo/gluster-users > >>> > >> > >>> _______________________________________________ > >>> Gluster-users mailing list > >>> Gluster-users@xxxxxxxxxxx > >>> http://supercolony.gluster.org/mailman/listinfo/gluster-users > > > _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
