[rrd-users] Re: how to merge 2 rrd-files

[McGlinchy, Alistair]

Alex et al,

> > Example 1:
> > You are running MRTG using 32bit SNMP counters and you want 
> to switch 
> > to 64 SNMP counters.  If you just change your configs you will get 
> > enormous spikes in each graph as the 64 bit counters will be much 
> > bigger than the 32 bit, but may still be valid data for the RRD. My 
> > solution is to run MRTG with 64 bit counters and have it create a 
> > brand new RRD. Then you can merge the old RRD data from 32 bit 
> > collections into the new RRD.
> 
> Step 1:  stop updating using the 32-bit counter
> Step 2:  insert NaN in the stream (rrdtool update ... N:U)
> Step 3:  start updating using the 64-bit counter

Good idea! I hadn't realised that explicitly setting U would reset the
last value. I had assumed it was a null-op. That'll save some grunt work
... cheers!

> > Example 2:
> > Your collection server crashes and you are in a mad panic. 
> You start 
> > up collections on a separate server while you fix your 
> server.  What 
> > do you do with the data collected on the backup server when your 
> > normal collection box is fixed...?
> 
> Step 1: update both databases simultaneously (so that they're 
> in sync) Step 2: a:  rrdtool dump database1.rrd > database1.xml
>         b:  rrdtool dump database2.rrd > database2.xml
> Step 3: copy interesting parts from both xml files into a 
> third Step 4: rrdtool restore newdatabase.xml newdatabase.rrd

Um... this is exactly what the perl script I posted does. Note that for
the standard MRTG RRD "interesting" means 8 different places with some
non-trivial alignment issues. That's not something I want to do manually
with even one RRD file let alone the other 17000 RRDs that are updated
every 5min on our production server. I need a tool that can re-merge in
the old data without disrupting live collections.

> This is the most complex solution.  Then again, how often are 
> you going to make this mistake?

I still have to plan for what I will do if/when my collection server
dies.  What did happen that was almost as bad was when a sysadmin
accidentally increased the system clock by a month on a Saturday I came
in on a Monday and had flat-lines for a month on all my graphs. I would
be interested to hear suggestions on the most effective way to tidy up
from that.


Cheers

Alistair


-----------------------------------------------------------------------


Registered Office:
Marks and Spencer plc
Waterside House
35 North Wharf Road
London
W2 1NW

Registered No. 214436 in England and Wales.

Telephone (020) 7935 4422
Facsimile (020) 7487 2670

www.marksandspencer.com

Please note that electronic mail may be monitored.

This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful.

The registered office of Marks and Spencer Financial Services PLC, Marks and Spencer Unit Trust Management Limited, Marks and Spencer Life Assurance Limited and Marks and Spencer Savings and Investments Limited is Kings Meadow, Chester, CH99 9FB. These firms are authorised and regulated by the Financial Services Authority. 

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi