[rrd-users] Locking *read* (copy/backup) of RRD files?

[Steve Shipway]

> > This could be a good application of rrd cache chaining, if I can get
> > it working well.  This would allow you to set up your rrdcached to
> > chain to another local rrdcached which holds the backup; everything
> > writes via the first rrdcached.  If you want to backup, you kill the
> > secondary, backup the files, and restart it.
> >
> > The trouble with this is that the rrdcached chaining code (1) gets
> > upset if the remote rrdcached disappears, and (2) is not yet mature
> > enough to go into trunk.
> 
> I'm afraid that I see a (3): In the constellation you describe, the RRD
> files that get backed up would accumulate "holes" for every timeframe
> where the backup was run, holes which are absent from the primary set
> of RRD files. And the fact that you're blocking *all* RRD files for
> whatever time the *entire* backup run takes sort of maximizes the
> problem ...

True; however I'd use a filesystem snapshot so the time during which the rrdcached is inoperative would be measured in seconds, and the 'hole' would be single dp on a subset of the RRD files.

A better solution could be to add a 'pause' state to the rrdcached, during which it would not process the write thread.  Maybe a sigusr1 could pause the write thread and sigusr2 restart it, or simply use rrdcached commands, so that you could guarantee the files would be not updated, and pending updates would simply queue up in the rrdcached?  In this case, you'd not even need the chaining mode and second copy.  I rather like this idea so I'm going to investigate how hard it would be to implement.

> As a matter of fact, I'm a bit surprised to see that rrdresize seems to
> be the *only* part of rrdtool which sets a(ny) lock while *reading* an
> RRD file.

I'd need to check, but possibly since the RRD file size is constant (except when running rrdresize) it means that since reads and writes are atomic, the reads do not need to be locked as you will always get consistent data?

Steve

Steve Shipway
ITS Unix Services Design Lead
University of Auckland, New Zealand
Floor 1, 58 Symonds Street, Auckland
Phone: +64 (0)9 3737599 ext 86487
DDI: +64 (0)9 924 6487
Mobile: +64 (0)21 753 189
Email: s.shipway at auckland.ac.nz
 Please consider the environment before printing this e-mail