[Gluster-users] geo replication help

[M S Vishwanath Bhat]

On 15/08/14 15:55, Niels de Vos wrote:
> 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?
Apologies to the delay. We had long weekend and I was out of town having 
no access to emails.

The issue was some design limitation/flaw with xsync in 3.5. And the 
issue is fixed by introducing changelog history APIs. These changes are 
present only in upstream as of now. Not sure if it can be backported to 
3.5 but should be included in 3.6 at least.

I am cc'ing Aravinda, who is maintaining of geo-rep. He would provide 
the list of bugs/patches which should be backported.

Best Regards,
Vishwanath


>
> 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