Re: Question about geo-replication and deletes in 3.5 beta train

CJ Beck <chris.beck@xxxxxxxxxxx> · Wed, 16 Apr 2014 21:31:29 +0000

I did have the “change_detector” set to xsync, which seems to be the issue (bypassing the changelog method). So I can fix that and see if the deletes are propagated.

Also, is there a way to tell the geo-replication to go ahead and walk the filesystems to do a “sync” so the remote side files are deleted, if they are not on the source?

Thanks for the quick reply!

[root@host ~]# gluster volume geo-replication test-poc 10.10.1.120::test-poc status detail

MASTER NODE               MASTER VOL    MASTER BRICK     SLAVE                     STATUS     CHECKPOINT STATUS    CRAWL STATUS    FILES SYNCD    FILES PENDING    BYTES PENDING    DELETES PENDING    FILES SKIPPED
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
host1.com    test-poc       /data/test-poc    10.10.1.120::test-poc    Passive    N/A                  N/A             382            0                0                0                  0
host2.com    test-poc       /data/test-poc    10.10.1.122::test-poc    Passive    N/A                  N/A             0              0                0                0                  0
host3.com    test-poc       /data/test-poc    10.10.1.121::test-poc    Active     N/A                  Hybrid Crawl    10765          70               0                0                  0

From: Venky Shankar <yknev.shankar@xxxxxxxxx>

Date: Wednesday, April 16, 2014 at 1:54 PM

To: CJ Beck <chris.beck@xxxxxxxxxxx>

Cc: "gluster-users@xxxxxxxxxxx" <gluster-users@xxxxxxxxxxx>

Subject: Re:  Question about geo-replication and deletes in 3.5 beta train

"ignore-deletes" is only valid in the initial crawl mode[1] where it does not propagate deletes to the slave (changelog mode does). Was the session restarted by any chance?

[1] Geo-replication now has two internal operations modes: a one shot filesystem crawl mode (used to replicate data already present in a volume) and the changelog mode (for replicating
 live changes).

Thanks,

-venky

On Thu, Apr 17, 2014 at 1:25 AM, CJ Beck 
<chris.beck@xxxxxxxxxxx> wrote:

I have an issue where deletes are not being propagated to the slave cluster in a geo-replicated environment. I’ve looked through the code, and it appears as though this is something that might have been changed to
 be hard coded?

When I try to change it via a config option on the command line, it replies with a “reserved option” error:

[root@host ~]# gluster volume geo-replication test-poc 10.10.1.120::test-poc config ignore_deletes 1
Reserved option
geo-replication command failed
[root@host ~]# gluster volume geo-replication test-poc 10.10.1.120::test-poc config ignore-deletes 1
Reserved option
geo-replication command failed
[root@host ~]#

Looking at the source code (although, I’m not a C expert by any means), it seems as though it’s hard-coded to be “true” all the time?

(from glusterd-geo-rep.c):

4285         /* ignore-deletes */
4286         runinit_gsyncd_setrx (&runner, conf_path);
4287         runner_add_args (&runner, "ignore-deletes", "true", ".", ".", NULL);
4288         RUN_GSYNCD_CMD;

Any ideas how to get deletes propagated to the slave cluster?

Thanks!

-CJ

_______________________________________________

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