History Database purge and compact

History database is supposed to contains “all history data”, but if you want to delete old data, or compact them, you will need to execute pandora_db script with a “fake” configuration data, to let it think is the “normal” behaviour. To do this, you need to enter some data in your History Database.

First, you need to “recreate” a functional table values in tconfig, with useful values to be used by pandora_db tool. Use this SQL queries on your history database to create a minimal configuration for the behaviour of the pandora_db running against history database. You first need to connect your database, using MySQL CLI tool.

This is an example, replace values as you needed (but let history_db_enabled to zero 0):

INSERT INTO `tconfig` VALUES (1,'days_purge','180');
INSERT INTO `tconfig` VALUES (2,'history_db_enabled','0');
INSERT INTO `tconfig` VALUES (3,'days_compact','120');
INSERT INTO `tconfig` VALUES (4,'step_compact','1');

This means data in history is stored for 6 months (starting from now), and compacted from 4th month. If you have 1 month of data in your “main” database, you will have a total of 6 months of data, because the last month is coming from the main database, and the other five from the history database. You can put any value here, there is no limit of data storage in history database. Just remember, history database must be in a different physical server, not in the same host/system where is the main database and/or running Pandora FMS server or console.

Second, you need to create an additional pandora_server.conf file, use this “small version” to create your own (replace the values for your history database values), name it /etc/pandora/pandora_server_history_db.conf :

dbengine mysql
dbname pandora4_history
dbuser pandora4_history
dbpass 1234
dbhost 192.168.50.23
log_file /var/log/pandora/pandora_db_history.log

Now you can execute pandora_db tool against the “fake” configuration:

/usr/share/pandora_server/util/pandora_db.pl /etc/pandora/pandora_server_history_db.conf

This process should not affect your main operation because is running against a different database in a different server. The only possible delay should be if someone is trying to render a big amount of data from history, that will take more time than usual.