Re: RRDcached chaining mode

As far as I can see, it is working fine, although ONLY for UPDATE -- really we should chain at least INFO, and probably FLUSH as well.  The biggest risk, as I see it, is a memory leak somewhere.

I've not made any more changes to the code since I posted it; I've just left it running here in our environment to see if there are any memory issues (none so far, since the other errors were picked up on...)

I was hoping for some feedback from the rest of the rrd-developers community before passing it on to you officially, but people have been too busy, I guess

Steve

Steve Shipway
University of Auckland ITS
UNIX Systems Design Lead
[email protected]
Ph: +64 9 373 7599 ext 86487


________________________________________
From: Tobias Oetiker [[email protected]]
Sent: Wednesday, 22 December 2010 8:01 p.m.
To: Steve Shipway
Cc: [email protected]
Subject: Re: [rrd-developers] RRDcached chaining mode

Steve,

what is the state on this patch ?

Comments ?

cheers
tobi

Oct 4 Steve Shipway wrote:

> 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


--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900