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@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
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
