[Gluster-users] geo-replication delay?

[Venky Shankar]

Hi James,

Just checking back -- were you able to test it out with the config option?

Thanks,
-venky


On Wed, May 7, 2014 at 11:07 PM, Venky Shankar <yknev.shankar at gmail.com>wrote:

>
>
>
> On Wed, May 7, 2014 at 6:10 PM, James Le Cuirot <chewi at aura-online.co.uk>wrote:
>
>> Hello,
>>
>> I know this has been asked before but I felt that it wasn't fully
>> answered and I think the situation may have changed in 3.5.
>>
>> I have set up geo-replication between two machines on my LAN for
>> testing. Both are using NTP and the clocks are definitely in sync.
>> CRAWL STATUS reports Changelog Crawl. When I make a change on the
>> master, it takes up to a minute (sometimes less) for the slave to
>> notice.
>>
>
> ​That's because the change​ detection interval is 60 seconds by default[1]
> in 3.5. This has been changed to 15 seconds lately.
>
>
>> Now I understand that geo-replication will always have some delay, not
>> least because it is asynchronous, but given these are tiny changes with
>> practically no other activity going on, I was expecting it to be a
>> little more responsive. Even in production, there will very little
>> traffic so some additional resource usage to speed things up would not
>> be an issue. Is this configurable at all?
>>
>
> ​It's configurable. Try this:
>
> # gluster volume set <volume> rollover-time 1
>
> to indentify changes (followed by syncing it to the slave) every second.
> This will definitely speed up replication.
>
>
>
>>
>> I've seen it explained previously that inotify does not scale well and
>> gluster has taken a more efficient approach. I hadn't expected this to
>> come at the cost of such long delays though. We're only planning to
>> have two nodes, a master and a slave, and I've also seen it said that
>> gluster provides little benefit over a simple periodic call to rsync
>> under such setups. Combine that with inotify and the rsync solution
>> even starts to look favourable.
>>
>> Lowering this delay is not a deal-breaker for us, it's just that it
>> seems unnecessarily long. I'd appreciate hearing your thoughts.
>>
>
> ​[1]:
> https://github.com/gluster/glusterfs/blob/release-3.5/xlators/features/changelog/src/changelog.c#L1556
> ​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140509/26cdcc4d/attachment.html>