[Gluster-users] Question about geo-replication and deletes in 3.5 beta train

Venky Shankar yknev.shankar at gmail.com
Wed Apr 16 23:43:55 UTC 2014


On Thu, Apr 17, 2014 at 3:01 AM, CJ Beck <chris.beck at workday.com> wrote:

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

​Was that set intentionally? Setting this as the main change detection
mechanism would crawl the filesystem every 60 seconds to replicate the
changes. Changelog mode handles live changes, so any deletes that were
performed before this option was set would not be 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?
>

​As of now, no. With distributed geo-replication, the geo-rep daemon crawls
the bricks (instead of the mount). Since the brick would have a subset of
the file system entities (for e.g. in a distributed volume), it's hard to
find out purged entries without having to crawl the mount and comparing the
entries b/w master and slave (which is slow). This is where changelog mode
helps.


>
>  Thanks for the quick reply!
>
>  [root at 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 at gmail.com>
> Date: Wednesday, April 16, 2014 at 1:54 PM
> To: CJ Beck <chris.beck at workday.com>
> Cc: "gluster-users at gluster.org" <gluster-users at gluster.org>
> Subject: Re: [Gluster-users] 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 at workday.com> 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 at host ~]# gluster volume geo-replication test-poc 10.10.1.120::test-poc
>> config ignore_deletes 1
>> Reserved option
>> geo-replication command failed
>> [root at host ~]# gluster volume geo-replication test-poc 10.10.1.120::test-poc
>> config ignore-deletes 1
>> Reserved option
>> geo-replication command failed
>> [root at 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 at gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140417/b9b7a2bf/attachment.html>


More information about the Gluster-users mailing list