[Gluster-users] geo replication help

M S Vishwanath Bhat vbhat at redhat.com
Mon Aug 18 09:32:41 UTC 2014


On 13/08/14 20:02, David F. Robinson wrote:
> One other question... Is there a way to set a config variable to turn 
> off the compression for the rsync?
You can use "rsync-options" to specify any rsync options that you want 
to rsync to use. Just make sure that it does not conflict with the 
default rsync options used by geo-rep.

For example,

#gluster volume geo-replication <MASTER> <SLAVE> config rsync-options 
'--bwlimit=<value>'

Best Regards,
Vishwanath

> David
> ------ Original Message ------
> From: "M S Vishwanath Bhat" <vbhat at redhat.com <mailto:vbhat at redhat.com>>
> To: "David F. Robinson" <david.robinson at corvidtec.com 
> <mailto:david.robinson at corvidtec.com>>; gluster-users at gluster.org 
> <mailto:gluster-users at gluster.org>
> Sent: 8/13/2014 6:47:11 AM
> Subject: Re: [Gluster-users] geo replication help
>> 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.
>>
>> 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
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140818/36c0fab9/attachment.html>


More information about the Gluster-users mailing list