On 03/09/14 20:31, David F. Robinson wrote:
Is this bug-fix going to be in the 3.5.3 beta release?
Not sure. I will have to check that. AFAIK the patches are present in
upstream and 3.6 branch. Is upgrading to 3.6 an option?
Best Regards,
Vishwanath
David
------ Original Message ------
From: "Niels de Vos" <ndevos@xxxxxxxxxx>
To: "M S Vishwanath Bhat" <vbhat@xxxxxxxxxx>
Cc: "David F. Robinson" <david.robinson@xxxxxxxxxxxxx>;
gluster-users@xxxxxxxxxxx
Sent: 8/15/2014 6:25:04 AM
Subject: Re: geo replication help
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?
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
