At 01:10 PM 9/11/2015 -0400, Mark Tompsett wrote:
Greetings,
I would suggest the <http://cleanup_database.pl>cleanup_database.pl script in the cronjobs directory, except I've just looked at it and it doesn't touch the import_items or import_biblios tables.
As Galen mentioned it does via cascades. Thanks for pointing me at the better way.
+1 (at least for Z39.50.) However for "cleaning up" purposes on a limited VM machine, what's the size of your inno file? On my sandbox (perhaps a tad smaller than your example): root@[my_sandbox]:/var/lib/mysql# ls -l total 1282100 -rw-rw---- 1 mysql mysql 1302331392 Sep 11 17:45 ibdata1 which is significant (nearly 4x the clean [1] sql dump at 354330649.) (To get rid of it in production, you have to delete all MySQL tables before removing this overweight monstrosity, then restore your dumps - takes only a few seconds on a fast machine, so I've set up the cron for "idle hours". Note this is a MySQL problem, not Koha; there was some talk that MySQL 5.6 would alleviate it, but my experience is that it does not -- only partiallytested, we're still using 5.5.44 in production.) Best -- Paul [1] I have things set up to run: ./bin/cronjobs/cleanup_database.pl --import 1 && ./bin/cronjobs/cleanup_database.pl --mail && ./bin/cronjobs/cleanup_database.pl --sessions && ./bin/cronjobs/cleanup_database.pl --logs 10 && ./bin/cronjobs/cleanup_database.pl --zebraqueue 1 before mysqldump --user=[munged] --password=[munged] > [munged]/backup/kohadump_{date}.sql