This would remove the actual accounting information. This won't break anything but would destroy data.
Because we are using ndo to push Nagios Core dataset into mysql, your data takes up twice the space. Some processes will use one location while others will use the other. When this is corrected we will implement removal of anything thought unnecessary.
Thanks a lot. but still have a question... Does system auto purge this table and archive directory?
IF YES, how often?
IF NOT, Can we purge records in nagios.nagios_logentries older than 1 month and log files in /usr/local/nagios/var/archives/ as well? This will sync nagios.nagios_logentries with nagios core datasets. Is this way safe? or you will suggest a better way to do that?
Since we start this XI instance in May, table nagios.nagios_logentries has been reached 790.3 MB, /usr/local/nagios/var/archives/ to 29MB. It might not be a problem recently but might be in the future. Our roll-out is not even half way.
Please provide us a save way to purge the archive logs? I believe that will be only 2 needs to pay attention.
This information is kept for historical information. It's unfortunate that the database grows so quickly to such a size.
I'd suggest getting a 2T or 4T drive, when you next run out of space a Petabyte should be affordable.
For a free solution obviously database maintenance would be one option. We may not be the best ppl to ask about such things and the ppl I've asked all say the same thing, get bigger disks. It sounds like MySQL dosen't support being small or free.
In you previos reply, you have mentioned about "accounting information". What "accounting infomation" is that?
This would remove the actual accounting information. This won't break anything but would destroy data...
Also, no matter how big the drive is, the database grooming policy or aged records purging process should alway be asked by DBA in most of organization.
Nagios keeps track of availability and other statistics. If you choose to purge this data these reports would be lost for the time period in question. From a system administration stand point it's essential to have a complete history to accurately determine the frequency of an error.
I'm not sure I'd consider these to be aged as these records represent current history until after the host/service they belong too is deleted.