[Gluster-users] geo replication help
M S Vishwanath Bhat
vbhat at redhat.com
Wed Aug 13 10:47:11 UTC 2014
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
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.
> */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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users