Gluster users - May 2014 - geo-replication delay?

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.

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?

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.

Regards,
James

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/20140507/744d7e86/attachment.html>