ADMIN_archive_log_tables.pl

[scrublord]

Hello.

I am currently using a Vicidial cluster, all installed via ISO, version 5.0.3. There is a dedicated database server, webserver, and multiple dialers. Since it is so much to list, I am not going to. The setup works and works well except for one problem: vicidial_log, vicidial_agent_log and a few others have grown to ridiculous numbers and are taking forever to make routine queries during operations. We do a massive amount of outbound dialing.

This system worked flawlessly for the first few days then started experiencing delays in the agent's screens between calls. They will periodically get two calls dropped into their conferences as well. After checking a few things, ensuring that everything was set up properly, making sure that the network was behaving properly, it was still happening. I set long_query_time to 1 in my.cnf to verify my suspicions that it was bottlenecking at the database. It was set to 3 before, and missing all of the queries taking two and a half seconds. There were a LOT of them taking over 1 second.

I counted the rows in vicidial_log, vicidial_agent_log, and a few other tables, and they have all grown to have over 5 million records. I ran ADMIN_archive_log_tables.pl, and apparently it saves 1 month worth of records in these tables even though --daily is specified.

My question is twofold: Is there a way to archive those logs daily or weekly rather than monthly? If not, would it break things if I just did it manually?

Thanks.

[williamconley]

[--daily] = only archives call_log, vicidial_log_extended and vicidial_dial_log tables, only last 24 hours kept

And to answer your question: NO, it will not harm your system if you manually perform this task, assuming you don't break anything while doing it. Copy the log files to the archive versions of the tables, then delete the ones you no longer need in the live log tables. You'll lose reporting on those missing records, of course. For best performance, you would actually empty the entire table (cleans the mysql file out completely, no frags!).

You COULD copy these to a virtual vicidial and restore them to their original tables for reporting, if you like. Then your reporting system would be completely independent and cause no problems with your live server.