[Gluster-users] geo-replication delay?
Venky Shankar
yknev.shankar at gmail.com
Wed May 7 17:37:17 UTC 2014
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>
More information about the Gluster-users
mailing list