Attached is a small patch for rrdtool to allow chaining of update requests 
received via rrdcached on to a second instance of rrdcached specified by a 
command line parameter -C.

EG:
$ rrdcached -l unix:/tmp/a.sock -b /var/rrda
$ rrdcached -l unix:/tmp/b.sock -b /var/rrdb -C unix:/tmp/a.sock
$ rrdtool update --daemon unix:/tmp/b.sock foo.rrd N:1:1

This updates foo.rrd in both /var/rrdb and /var/rrda, provided it exists, of 
course.  This also works over TCP sockets, and you can mix and match UNIX and 
TCP sockets if you like.  This patch only chains UPDATE requests, not CREATEs, 
STATs, or anything else.

The requests are sent to the remote daemon immediately after they are added to 
the update queue for the receiving daemon (thus avoiding any trouble of how to 
handle them after queueing).  If the relay fails then an error is logged BUT 
the rrdcached still returns a success code to the remote client (as there is no 
'warning' code for a partial success).

I've run this here for a few days keeping a shadow copy of our secondary MRTG 
server's RRD files, and it worked without problem.  There was a bit of an issue 
when I defined two instances to chain to each other, though :)

I think it would need to have CREATE, and probably FLUSH, FLUSHALL and STATS 
chained as well for this to be of real use.

Thoughts?

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.ship...@auckland.ac.nz<mailto:s.ship...@auckland.ac.nz>
P Please consider the environment before printing this e-mail


Attachment: rrd-chain.diff
Description: rrd-chain.diff

_______________________________________________
rrd-developers mailing list
rrd-developers@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers

Reply via email to