[Gluster-users] geo replication help

[M S Vishwanath Bhat]

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?

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
>