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